- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 8 Dec 2011 14:40:59 -0800
On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller <erights at google.com> wrote: > Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:* > header, the API you suggest below can be fully implemented as a library. > > Since any response that parses as JavaScript has no same origin protection > anyway, rather than carve out a special case for JSONP, should we waive > the?ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as > JavaScript for XHR requests in general? If not, what justifies carving out a > special case for JSONP? There's two *possible* reasons to treat JSONP special. The weak reason would be to support existing JSONP-serving servers which are out there already. JSONP appears to be one of the more popular formats for HTTP-based APIs right now. The stronger reason is that it appears that people have a very hard time setting http headers. While this seems surprising to me, especially in situations like this where you already have server-side scripts generating dynamic content, it is feedback that I get *a lot*. Another option would be some way to express CORS signals inline in content. This actually existed in early CORS drafts, but only for XML based contents which made it a lot less appealing. Especially since the XML based content had to be served with a proper Content-Type header which puts us back at square one. / Jonas
Received on Thursday, 8 December 2011 14:40:59 UTC