W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 8 Dec 2011 14:40:59 -0800
Message-ID: <CA+c2ei-h1DX07L5GTqXO_MGTUy+WF9-fDEVLc6acfvjvnteMYA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:38 UTC