- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 20 Jun 2013 17:48:38 +0900
- 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