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/>
