- From: Anne van Kesteren <annevk@opera.com>
- Date: Sat, 24 Jan 2009 16:03:05 +0100
- To: "Adam Barth" <w3c@adambarth.com>
- Cc: "WebApps WG" <public-webapps@w3.org>
I read the 23 January 2008 version of http://webblaze.cs.berkeley.edu/2009/origin/origin.txt 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. 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. Another change is that you allow the value "null" to be used at will, which if implemented would make it less useful. 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. 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? 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? 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. Thanks for working on this by the way! -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Saturday, 24 January 2009 15:03:51 UTC