JSONP or "JSON with padding" is a complement to the base JSON data format. It provides a method to request data from a server in a different domain,something prohibited by typical web browsers because of the Same origin policy.

Under the same origin policy,a web page served from server1.example.com cannot normally connect to or communicate with a server other than server1.example.com. An exception is the HTML <script> element. Exploiting the open policy for <script> elements,some pages use them to retrieve JavaScript code that operates on dynamically generated JSON-formatted data from other origins. This usage pattern is known as JSONP. Requests for JSONP retrieve not JSON,but arbitrary JavaScript code. They are evaluated by the JavaScript interpreter,not parsed by a JSON parser.

There have been some criticisms raised to JSONP. Cross-Origin Resource Sharing is a more recent method of getting data from a server in a different domain,which addresses some of those criticisms.

[edit] How it works

To see how this pattern works,first consider a URL which on request returns a JSON document. A JavaScript program might request this URL via XMLHttpRequest,for example. Suppose a URL is http://server2.example.com/RetrieveUser?UserId=xxx. Suppose the UserId of Foo is 1234. A browser requesting the URL http://server2.example.com/RetrieveUser?UserId=1234,passing the UserId of Foo,might receive something like:

   {@H_404_201@"Name": @H_404_201@"Foo", @H_404_201@"Id" : 1234, @H_404_201@"Rank": 7}

This JSON data could be dynamically generated,according to the query parameters passed in the URL.

Now imagine specifying a URL that returns JSON as the src attribute for a <script> element. The problem with this is that the JSON is evaluated as JavaScript,but instead of interpreting the content as object literal,it would be interpreted as a block and throw a Syntax error. Even if it was correctly interpreted as object literal,it cannot be accessed by JavaScript as it is not assigned to a variable.

In the JSONP usage pattern,the src attribute in the <script> element returns dynamically generated JSON,with a function call wrapped around it. In this way,the returned resource is still legal JavaScript,but because the anonymous object literal is wrapped in a function call,the browser's JavaScript environment can act on the returned data. It might look like this:

   functionCall({@H_404_201@"Name": @H_404_201@"Foo", @H_404_201@"Rank": 7});

The function call is the "P" of JSONP - the "padding" around the pure JSON,or according to some^[1] the "prefix". By convention,the browser provides the name of the callback function as a named query parameter,typically using the name jsonp or callback,in its request to the server,e.g.,

 <script type="text/javascript"
 src="http://server2.example.com/RetrieveUser?UserId=1234&jsonp=parseResponse">
 </script>

In this example,the received payload would be:

   parseResponse({@H_404_201@"Name": @H_404_201@"Foo", @H_404_201@"Rank": 7});

[edit] Padding

While the padding (prefix) is typically the name of a callback function that is defined within the execution context of the browser,it may also be a variable assignment,an if statement,or any other JavaScript statement. The response to a JSONP request (namely,a request following the JSONP usage pattern) is not JSON and is not parsed as JSON; the returned payload can be any arbitrary JavaScript expression,and it does not need to include any JSON at all. But conventionally,it is a JavaScript fragment that invokes a function call on some JSON-formatted data.

Said differently,the typical use of JSONP provides cross-domain access to an existing JSON API,by wrapping a JSON payload in a function call.

[edit] Script element injection

JSONP makes sense only when used with a script element. For each new JSONP request,the browser must add a new <script> element,or reuse an existing one. The former option - adding a new script element - is done via dynamic DOM manipulation,and is known as script element injection. The <script> element is injected into the HTML DOM,with the URL of the desired JSONP endpoint set as the "src" attribute. This dynamic script element injection is usually done by a javascript helper library. jQuery and other frameworks have JSONP helper functions; there are also standalone options. ^[2]

The dynamically injected script element for a jsonp call looks like this:

 <script type="text/javascript"
 src="http://server2.example.com/RetrieveUser?UserId=1234&jsonp=parseResponse">
 </script>

After the element is injected,the browser evaluates the element,and performs an HTTP GET on the src URL,retrieving the content. Then the browser evaluates the return payload as javascript. This is typically a function invocation.

In that way,the use of JSONP can be said to allow browser pages to work around the same origin policy via script element injection.

[edit] Security concerns

Including script tags from remote sites allows the remote sites to inject any content into a website. If the remote sites have vulnerabilities that allow JavaScript injection,the original site is exposed to an increased risk.

An effort is underway to define a safer strict subset definition for JSON-P^[3] that browsers would be able to enforce on script requests with a specific MIME-type such as "application/json-p". If the response didn't parse as strict JSON-P,the browser could throw an error or just ignore the entire response. For the moment however the correct MIME-type is "application/javascript" for JSONP.

[edit] Cross-site request forgery

Naive deployments of JSONP are subject to cross-site request forgery (CSRF or XSRF) attacks.^[4] Because the HTML <script> tag does not respect the same origin policy in web browser implementations,a malicIoUs page can request and obtain JSON data belonging to another site. This will allow the JSON-encoded data to be evaluated in the context of the malicIoUs page,possibly divulging passwords or other sensitive data if the user is currently logged into the other site.

This is problematic only if the JSON-encoded data contains sensitive information which should not be disclosed to a third party,and the server depends on the browser's Same Origin Policy to block the delivery of the data in the case of an improper request. There is no problem if the server determines the propriety of the request itself,only putting the data on the wire if the request is proper. Cookies are not by themselves adequate for determining if a request was authorized. Exclusive use of cookies is subject to cross-site request forgery.

[edit] History

In July 2005 George Jempty suggested an optional variable assignment be prepended to JSON.^[5][6] The original proposal for JSONP,where the padding is a callback function,appears to have been made by Bob Ippolito in December 2005@H_301_566@[7] and is now used by many Web 2.0 applications such as by Dojo Toolkit, Google Web Toolkit,^[8] and Web services.

[edit] References

[edit] External links

• Official website
• About JSONP in JavaScript
• jsonp-java wraps any response content into a jsonp callback
• An implementation of a JSONP utility class