- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 04 Feb 2009 13:33:26 +0100
- To: "Adam Barth" <w3c@adambarth.com>
- Cc: "WebApps WG" <public-webapps@w3.org>
On Sat, 24 Jan 2009 19:39:10 +0100, Adam Barth <w3c@adambarth.com> wrote: > On Sat, Jan 24, 2009 at 7:03 AM, Anne van Kesteren <annevk@opera.com> > wrote: >> I'm wondering whether it's a good idea to define that the Origin header >> is always included for all those type of requests. Is that really what >> we want? Or do we want to use it for CORS, HTML form submission, and >> maybe future >> APIs that allow equivalent functionality? E.g., it does not seem >> important for curl or wget to support Origin, even though they >> sometimes perform POST requests as well. > > It is important that the attacker can't trick the browser into sending > a POST request without an Origin header because Web sites are supposed > to treat those requests as if they came from non-supporting user > agents and let the request modify state. Ok, I suppose that makes sense. > We could explicitly define the notion of a participating user agent, > much as we do for servers. This would let curl or wget ignore the > header since it's not important for them. I think that would make sense. >> As currently drafted it introduces a change as opposed to how Origin has >> been defined in CORS. Per your draft it will also be included for same >> origin requests. > > Yes. This is a change. The presence of the Origin header with the > correct value is more confidence inspiring for those using the header > as a CSRF defense. Also, if the header achieves widespread > deployment, server operators might choose to lock out legacy clients > by blocking state-changing requests that lack an Origin header. Ok. >> Another change is that you allow the value "null" to be >> used at will, which if implemented would make it less useful. > > My intention was that other specifications, like CORS and HTML forms, > would require the Origin header to be non-null for particular APIs. > That way CORS would have the same functionality it has now. Ok. >> I don't understand you can come past step one in the section HTTP Server >> Behavior when you use an unsafe method. But then I have a hard time >> understanding the wording there in general so I may be missing >> something. > > Oops. That's a bug. Fixed. How can I improve the wording there to > make it more clear? It's ok now. I think the bug just tripped me. >> Is the second algorithm in the HTTP Server Behavior section intended for >> content deployed on a participating server which is then rendered in a >> browsing context? > > Yes. I wasn't sure how to specify this cleanly at this layer of > abstraction. I'd welcome any suggestions you have. Maybe talk about content or Web pages rather than a server? Dunno. >> As for the sections with definitions, how do we ensure consistency with >> the >> origin model in HTML5? Would HTML5 defer to this draft for computing an >> origin out of a URI? What about comparing origins? > > That's the plan. Ian and I are working out the cleanest way to do this. > >> Unicode serialization of >> an origin is not used in the draft yet is defined. Is there a strategy >> behind this? It might help to outline that in the draft. > > It didn't make sense to spec the ASCII serialization in one document > and the unicode serialization in another document. Ok. One other thing, CORS currently requires codepoint for codepoint comparison between two origins. Your draft seems to suggest that servers should implement a different algorithm. Why can servers not use string comparison as well given that the origin they will get will always be the same for a given URL? -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Wednesday, 4 February 2009 12:34:10 UTC