W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Fetch: please review!

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 20 Jun 2013 17:48:38 +0900
Message-ID: <CADnb78gtg=SRbob3nSXbqWAjq-ed8gKnHiKhCPW9MedXGxR7Hg@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>
On Fri, Jun 7, 2013 at 8:15 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> http://fetch.spec.whatwg.org/#cors-same-origin contains the following:
>
> """A response is either CORS-same-origin or CORS-cross-origin. Unless otherwise
> indicated a response is CORS-same-origin."""
>
> but it doesn't say what the difference is between the two. The 'CO' in CORS
> stands for 'cross origin' so 'CORS-same-origin' would mean 'cross origin
> sharing for the same origin' which sounds a bit strange.

I borrowed this terminology from the HTML standard. Since using these
correctly in specifications requires detailed knowledge of
origin-based security expanding on them didn't seem all too useful.

I have been thinking about better terms. If we think about it in terms
of classes, the base class would be Response. Most everything (apart
from cookies/trailers, except maybe via special interfaces) is exposed
here.

Then there's TaintedResponse, what you get for <img
src=//crossorigin/>. With the usual caveats for exporting from
<canvas> and what not.

And then there's CORSResponse for <img src=//crossorigin/ crossorigin>
which has some limitations (e.g. on which headers are exposed by
default), but much less than TaintedResponse.

Moving towards that terminology would probably be a step up. I haven't
quite convinced myself it's a 100% accurate and works across all
specifications. Input welcome.


--
http://annevankesteren.nl/
Received on Thursday, 20 June 2013 08:49:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC