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

On Thursday, December 8, 2011, Jonas Sicking wrote:

> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller <erights at google.com<javascript:;>>
> 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.



>
> / Jonas
>


-- 
    Cheers,
    --MarkM

Received on Thursday, 8 December 2011 15:00:37 UTC