[whatwg] Behavior when <script> is removed from DOM

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


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>
>> 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.
>>
>
> My suggestion is that if the response parses as a JavaScript Program, this
> 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
> JavaScript, are not protected by same-origin.
>

It is possible that the data in responses that nominally parse as
JavaScript would not normally be available to cross-origin pages, no?


>
>
>
>>
>> / Jonas
>>
>
>
> --
>     Cheers,
>     --MarkM
>