JSONP Header Transfer Proposal
24 December 2007JSONP 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.
One Response to “JSONP Header Transfer Proposal”
August 7th, 2008 at 5:20 am
I understand what you are trying to achieve, but really I think when faced with a need to use HTTP headers, you should abandon JONP (which lets face it is a clumsy hack to get around a misfeature of Javascript), and do it properly. In this case, doing it properly would be using HTTP natively (i.e. through Javascript’s existing ability to make HTTP calls) and installing a server-side component to proxy the HTTP call and dodge the single origin policy issue.
Issuing an HTTP GET request that contains the querystring ‘httpMethod=POST’ should, I think, be a very big warning light to anyone that something has gone horribly wrong.