On Fri, Jun 7, 2013 at 8:15 PM, Rik Cabanier <caban...@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/