[whatwg] Behavior when <script> is removed from DOM
wycats at gmail.com
Thu Dec 8 15:08:57 PST 2011
On Thu, Dec 8, 2011 at 3:00 PM, Mark S. Miller <erights at google.com> wrote:
> On Thursday, December 8, 2011, Jonas Sicking wrote:
>> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller <erights at google.com>
>> > 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.
>> > anyway, rather than carve out a special case for JSONP, should we waive
>> > the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as
>> 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.
> is interpreted as an inline signal, since same-origin protection for these
> responses make no sense. The reason why you're willing to carve out a
> special case for JSONP is precisely because these responses, parsing as
It is possible that the data in responses that nominally parse as
>> / Jonas
More information about the whatwg