Why JSONP is still mandatory

http://blog.algolia.com/jsonp-still-mandatory/

by jlemoine • 12 years ago

39 20 12 years ago

blog.algolia.com

puppetmaster3• 12 years ago

It is a bit like having to support IE6.

At some point you have to move forward to CORS, because others have.

homakov2• 12 years ago

Not sure you made the right choice. This is how to use CORS without Preflights: http://homakov.blogspot.com/2014/01/how-to-use-cors-without-...

And this is why JSONP is almost always a bad idea (for sensitive data): http://homakov.blogspot.com/2013/02/are-you-sure-you-use-jso...

jrochkind1• 12 years ago

* This is how to use CORS without Preflights: http://homakov.blogspot.com/2014/01/how-to-use-cors-without-...

Am I misreading, or is the thing you link to a proposal for what user-agents should do, rather than a technique that works now? Ah, I see you are the author of what you linked to, so maybe I am misreading?

(Also, are there secruity concerns with first making the request, and only finding out after you made it if you were allowed to make it? Seems like for POST requests (or GET requests on badly implemented apps), the request alone can be dangerous, even if the browser refuses to share the response with the script after seeing the response headers)

homakov2• 12 years ago

I proposed two techniques, putting all headers in Accept (works now) and allowing CORS-* headers by default (just a proposal)

lukebaker• 12 years ago

Would using HTTPS prevent the VPN and various proxies from messing with the traffic as described in the article?

jlemoine4• 12 years ago

The issue was the same with HTTPS. HTTPS does not prevent the problem since the firewall was blocking all OPTIONS request.

Arkadir2• 12 years ago

I'm curious: with HTTPS, how does the firewall know that it's an OPTIONS request ?

Udo3• 12 years ago

A different position would be to simply let these misconfigured and badly written networking programs fail - and let them fail hard.

Yes, it will be painful in the short term and users will notice outages, but in the long run it will result in these issues being fixed. If we continue a policy of reversion to bad workarounds (which is really what JSONP is), we not only add complexity and the potential for obscure exploits to our own software, we ensure that nobody at Cisco et al will ever feel the pressure to fix these bugs.

gress3• 12 years ago

Sacrificing a business and the livelihoods of it's employees is a steep price to pay for getting some bugs fixed.

Udo3• 12 years ago

I depends on the position you're in. If you're a scrappy B2B startup looking to gain traction, this is indeed not a battle you want to fight. But things look vastly different if you're Facebook or Techcrunch. Then the story suddenly becomes "there is a bug in our router that causes TC not to load, this needs to be fixed ASAP" instead of "screw this app, it doesn't seem work".

jlemoine4• 12 years ago

I am agree that JSONP is a bad workaround, but it is not an option to do nothing. The problem is that we have large-audience websites as customers, even with a patch from Cisco you cannot force all people to update their firewall, especially because there is no automatic software upgrade on this VPN.

gkop2• 12 years ago

Yes, you generally need a fallback when using CORS. When I can get away with it, I prefer running a proxy on my origin domain for this fallback, as it allows me to use all the headers I like (rather than JSONP).

The article doesn't mention that many modern browsers don't respect MaxAgeSec for caching the OPTIONS requests, at least not for more than a few minutes, which is another knock against CORS due to it causing 2x the number of requests versus JSONP.

Also the article doesn't mention that, once you've already moved all your header data into the body, you can make simple requests that don't require preflight OPTIONS requests [0] - which eliminates the problem with the 2x the requests.

[0] http://www.w3.org/TR/cors/#simple-cross-origin-request-0

jlemoine4• 12 years ago

I am the author of the post. You're right, I should have mentioned the OPTIONS related problems.

The first problem we have got with OPTIONS request is that the cache is only working for the full URL (including URL parameters). So you should prefer a POST API endpoint with parameters in the body instead of a GET API endpoint with parameters in the URL.

We have tested a lot caching of OPTIONS requests and we did not found any issue on recent browsers, they respect the cache is you specify the header Access-Control-Max-Age (they do not respect the Cache-Control header)

gkop2• 12 years ago

Thanks, you're right that the latest Chrome and Firefox are caching my OPTIONS.

Arkadir2• 12 years ago

At RunOrg, we've encountered this a few times with our CORS-only API.

It is against our philosophy to leave users behind only because they are locked in by outdated infrastructure. We still want to support them.

It is against our philosophy to bend the purity of our API to accommodate wrinkles in how outdated infrastructure declines to support standards. There will be no JSONP alternative to CORS in RunOrg.

The solution we propose each and every time is to mount a proxy to our API on the same domain as the site it is used on. Users on modern infrastructure reach us directly at api.runorg.com, users on CORS-hostile infrastructure reach us through the proxy and still get their data (albeit with decreased performance). It's a fairly simple technical solution that leavers our API clean and supports non-CORS modes of access.

Why JSONP is still mandatory

Related Stories