On Wed, 6 Mar 2013, Anne van Kesteren wrote: > > It seems we have a bunch of different policies for setting the Origin > header :-( > > XMLHttpRequest always sets it to the given value. > > HTML's "fetch" only sets it to a non-null value if a from parameter is > passed.
I originally wanted it to always be passed, but there are cases where that's not done for various reasons (mainly privacy or compatibility). The Origin spec handles this via "privacy-sensitive contexts"; if you look at the HTML spec source and search for "privacy-sensitive" you'll find relevant notes. > HTML's "potentially CORS-enabled fetch" seems to never invoke "fetch" > with a from parameter except indirectly via CORS' cross-origin request. Right, the idea there is to basically defer to CORS. On Thu, 7 Mar 2013, Anne van Kesteren wrote: > > So I also "tested" the "fetch from an origin" in the specification > http://dump.testsuite.org/fetch/form.html and it turns out that only > WebKit exhibits this behavior. Other browsers do not include Origin in a > navigation that uses the POST method. This is unsurprising, it's new requirements in old parts of the spec and it's unlikely browsers will be updated until it's something we test in the test suite. On Fri, 8 Mar 2013, Anne van Kesteren wrote: > > Okay. So currently the mix of the Origin specification and the HTML > specification suggests you either do "Origin: /origin/" or "Origin: > null". However WebKit seems to do "Origin: /origin/" or no header at all > (for the "privacy-sensitive" cases). Ian also mentioned that we can not > just put the Origin header into every outgoing request as that breaks > the interwebs (per research you did for Chrome I believe?). "Origin: null" is what the Origin spec requires, I think, so we should update that spec if we don't do that. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
