Comments on: JSONP: JSON With Padding

By: saeedneamati

saeedneamati — Mon, 26 Sep 2011 10:46:45 +0000

JSONP is an interesting concept, though I’ve encountered it just now, in 2011.

However, I still can’t think of a real-world example of it. Should we use it for example for authentication purposes where the authentication URL sends back a JSON object of the logged-in user as JSONP? Can you add some real-world examples AJAXIAN?

Thanks.

By: Dave Johnson » Blog Archive » Cross Domain AJAX with XML

Dave Johnson » Blog Archive » Cross Domain AJAX with XML — Sun, 09 Apr 2006 19:27:29 +0000

[...] On a post I made a few days back I proposed a way to do cross domain AJaX using XML rather than the commonly used JSON. It is essentially an extension of the idea of JSONP (JSON with Padding). Since I generally find myself working with XML more often than JSON I decided to create the equivalent for XML based applications. I have not extensively tested it but did try it on IE6 and FF1.5 on Win2K server. [...]

By: Ajaxian » Audible Ajax Episode 11: State of Ajax in Belgium

Ajaxian » Audible Ajax Episode 11: State of Ajax in Belgium — Wed, 18 Jan 2006 21:04:54 +0000

[...] JSONP: JSON With Padding [...]

By: Bob Ippolito

Bob Ippolito — Wed, 30 Nov -0001 00:00:00 +0000

Why NOT only prepend? There’s no reason to append. The more detail there is to the spec, the more likely somebody is going to implement it incorrectly on one side or the other. This is the simplest thing that could possibly work (for all use cases).

KISS.

By: Michael Mahemoff

Michael Mahemoff — Wed, 30 Nov -0001 00:00:00 +0000

Bob, agree that appending adds no new functionality, and in a protocol of this nature, that’s a pretty good argument to KISS and stick with only prepending.

The main argument for append is that I think we’ll see different idioms evolve in the whole area of remote scripting and JSON; adding a tiny bit more functionality in append just seems like it might encourage more creative uses to evolve.

I’m reluctant to mention specific examples, because my main point is that best practices will only come from real use. But one example would be appending a property value (ie. json + “.height”) or an array index (json + “[5]“).

By: Michal Migurski

Michal Migurski — Wed, 30 Nov -0001 00:00:00 +0000

From that article:

“Your page is still toast if the remote host decides to inject malicious code instead of JSON data. However, if implemented, it’d save a lot of developers some time and allow for generic abstractions, tutorials, and documentation to be built.”

I’ll take extra time over toasted pages any day of the week.

This idea was floated in the JSON-PHP group a few months back, and I felt pretty strongly that it was a bad one. Two reasons: 1) JSON isn’t just for javascript, so adding syntax that only makes sense in javascript narrows its utility. Even the parentheses break Doug’s simple spec. 2) Executing arbitrary responses from the server seems like a recipe for disaster. From this point of view, I’m not altogether satisfied with the simple “eval()” method for handling JSON responses.

There’s a lot of room for abuse in networked applications, and the excitement about API’s, XHR and JSON could lead to a serious Outlook-style problem for javascript apps in the near future.

By: David Carrington

David Carrington — Wed, 30 Nov -0001 00:00:00 +0000

I see no reason to do any work on the server for this (even just prepending a small string). It can be handled on the client entirely – in which case it is simply defining a callback function, which most AJAX code already does.

By: Bob Ippolito

Bob Ippolito — Wed, 30 Nov -0001 00:00:00 +0000

Michael,

that’s just silly.

Michal,

No. JSONP is an optional extension, if you don’t specify the jsonp query argument, then you get a normal JSON document. No compatibility is lost, specs aren’t broken.

eval() is perfectly safe for normal XMLHttpRequest. After all, it’s the same host you downloaded the JavaScript code from! If you can taint the JSON response, you surely could’ve tainted the code making it. The remote host case is another story, but *you don’t have a choice*.

JavaScript simply can’t efficiently receive data from remote servers, except when loading tags, which means full execute permission.

David,

If you don’t see a reason to do any work on the server, then RTFM. You’re wrong. It’s not possible to do this client-side in the context of browser JavaScript.