Viewed 3405 times

If you're building an AJA~Xy app, are there any downsides to using JSONP requests/responses even if you're not planning on any cross-domain requests?

The only thing I can think of is that there are a couple extra bytes for the callback wrapper...


I found this which also suggests security and error handling as potential problems...

There's no error handling. The script injection either works, or it doesn't. If there's an error from the injection, it'll hit the page, and short of a window wide error handler (bad, bad, very bad), you need to be sure the return value is valid on the server side.

I don't think error handling is much of a problem... most of us would use a library to generate the JSON... the well-formedness of my response isn't a concern for this question.

and security:

There are documents out on the web that can help, but as a cursory check, I would check the referrer in the server side script.

it seems like this is a potential problem with any type of response... certainly, there's nothing unique to JSONP in the security arena...?

4 answers given for "Are there reasons not to use JSONP for AJA~X requests?"

Accepted Solution

Downside? It's fairly limited - you trigger a "GET" request and get back some script that's executed. You don't get error handling if your server throws an error, so you need to wrap all errors in JSON as well. You can't really cancel or retry the request. You're at the mercy of the various browser author opinions of "correct" behavior for dynamically-generated <script> tags. Debugging is somewhat more difficult.

That said, i've used it on occasion, and haven't suffered. YMMV.

Retrieving errors when a jsonp call fails is possible.

Hope it helps.

I would say the biggest limitation might be the extra overhead for have the browser render a script tag to call the server. Plus is JSONP really considered AJAX since it doesn't actually use the XMLHttpRequest object?

Here is another bit you may want to consider with JSONP.. possible memory leaks..