Kris Zyp's Questionable Assumptions

December 24th, 2007
JSONP is a proposal for performing cross site JSON data interchange by using script tag insertion with a callback to deliver the data payload. JSONP can be used in place of XmlHttpRequest in cross site situations. However, when using XmlHttpRequest, there are situations where the JSON data in content body is not the only relevant information, but the response headers, as well other aspects of the HTTP request and response may also contain important information. I propose that JSONP can extended in a small and simple manner to accommodate the transfer of header information in suitably interoperable manner.

I propose when custom headers need to be included in the request, that headers simply be included as parameters. When servers that are responding to JSONP requests want to include response header information in the response, they may optionally respond with a second argument that contains header information in the form of an JSON object/map. The object should contain properties with the names corresponding to header names, and values corresponding to header values. The request format can remain the same:

http://myserver/requestJSON?callback=mycallback&Accept=application%2Fjson
And the response would look like:

mycallback({“name”:”foo”},{“Content-Type”:”application/json”,”Expires”:”Mon, 24 Dec 2007 17:09:04 GMT”})
This addition to JSONP should generally not break existing JSONP clients, as normally only one parameters is used. This allows JSONP to emulate more semantically correct manners of transferring information that conceptually belongs in headers.

Usages could include transferring the “Last-Modified” header, so clients could determine the freshness of the data, sending If-Modified-Since header in requests and many more.

In addition to transferring request and response headers, I propose that additional HTTP information could also be transferred in pseudo headers. The following pseudo headers may be used:

request
httpMethod – Indicates the HTTP method used (GET, POST, PUT, DELETE, etc).
httpContent – Indicates the body of the content of the HTTP request (such as the POST body)
httpNoCache – With non-idempotent methods, you should generally include an additional parameter with a random unique value to ensure that the request is not cached.
response
httpStatusCode – Indicates the HTTP status code.
httpStatusText – Indicates the HTTP status text.
A more sophisticated example request could be:

http://myserver/requestJSON?httpMethod=POST&httpNoCache=23n9zs92l&httpContent={“name”:”bar”}&callback=call1
And the response could be:

call1([{“name”:”foo”},{“name”:”bar”}],{”httpStatusCode”:200,”httpStatusText”:”OK”,”Date”:”Mon, 24 Dec 2007 17:09:04 GMT”})
Of course, this enables a greater level of interaction, and therefore the prerequisite security warnings must be heeded. You can get yourself in a lot of trouble with XSS if you are not using proper explicit authentication schemes.