MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin
The information regarding the "Fetch" API seems incorrect.
Note: The
Originheader is not set on Fetch requests with a method of HEAD or GET (this behavior was corrected in Firefox 65 — see bug 1508661).
(emphasis mine)
This, to me, appears to be trying to say that FF<65 sends the header, and FF≥65 does not. (I would be interested to see if anyone interprets this differently; I'm not 100% confident in my interpretation. Perhaps it should be edited for clarity in any case.)
I expected to see something that matched my testing:
Ctrl_Shift_k to open the Developer Tools (right now, on this page, at github.com.)
fetch('https://www.google.com/').then(console.log).catch(console.error);
XHR is enabled at the top-right of the log windowXHR GET ...", and scroll down within the Headers tab to the Request HeadrsOrigin header is sent, despite it being a GET request via the Fetch API (on Firefox 85.0)Diving into the bug discussion, it looks like not-sending-the-headers was either rolled back or never implemented. But, again, I'm not sure, so I'm escalating instead of just changing the page myself.
MDN Content page report details
en-us/web/http/headers/originThanks for reporting this. You are correct about that statement being wrong, and I’ll get it fixed.
For the record here: I think at least part of the reason that incorrect statement ended up getting added was that somebody who edited the article previously may have misinterpreted the following section of the Fetch spec:
https://fetch.spec.whatwg.org/#append-a-request-origin-header
To append a request
<code>Origin</code>header, given a request request, run these steps:
Let serializedOrigin be the result of byte-serializing a request origin with request.
If request’s response tainting is "
cors" or request’s mode is "websocket", then append `Origin`/serializedOrigin to request’s header list.Otherwise, if request’s method is neither `
GET` nor `HEAD`, then:
I guess somebody who edited the article previously must have read through that to step 3 and misinterpreted it as saying that the Origin header can _only_ end up getting added if request’s method is neither GET nor HEAD.
But what instead actually happens is that the Origin header _always_ gets added for all cross-origin requests.
That’s because step 2 requires that behavior — because all cross-origin requests, regardless of their method (including GET and HEAD requests) — have their response tainting set to cors.
In other words, for cross-origin requests, step 2 is an early return — that is, cross-origin requests never reach step 3.
So then in effect what step 3 part is saying is that only if the request isn’t a CORS request — that is, even if it’s a same-origin request — add the Origin header for all all request methods other than GET or HEAD; for example, same-origin POST requests always have an Origin header.
https://stackoverflow.com/a/66228794/441757 is a somewhat-related answer I wrote at Stack Overflow recently.
So, anyway, I’ll write up a patch for the https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin article using some succinct version of what I’ve described in this issue comment and in that Stack Overflow answer.
I think it might amount to replacing that entire Note with one sentence saying something like this:
Browsers add the
Originrequest header to all cross-origin requests — but also to all same-origin requests except for same-originGETorHEADrequests; for example, browsers add theOriginheader to all same-originPOST,OPTIONS,PUT,PATCH, andDELETErequests.
But actually, in the When browsers must send the Origin header section of the https://stackoverflow.com/a/42242802/441757 Stack Overflow answer, I got into more detail (a lot more…) — so maybe I should also try to port part of that to the MDN article.
FWIW @sideshowbarker
Suggested wording (your info "to my taste"):
Browsers add the Origin request header to:
- all cross-origin requests
- same-origin request except for GET or HEAD requests (i.e. they are added to same-origin POST, OPTIONS, PUT, PATCH, and DELETE requests).
PS Untangling these specs takes me forever. You're very good at it.
FWIW @sideshowbarker
- I'd add your note immediately and come back to considering the other stuff from stackoverflow later. Reason - it's much better and can be done quickly.
Yep — thanks much, that’d be great
- The bug info in the note is still relevant right? But should be in BCD.
Right, still relevant, but BCD is the right place
Suggested wording (your info "to my taste"):
Browsers add the Origin request header to:
- all cross-origin requests
- same-origin request except for GET or HEAD requests (i.e. they are added to same-origin POST, OPTIONS, PUT, PATCH, and DELETE requests).
Perfect (including putting it into a bulleted list — makes the distinction even more clear)
PS Untangling these specs takes me forever. You're very good at it.
I’ve just had to learn it the hard way. The Fetch doesn’t make anything easy. I feel like my relationship with has become a kind of Stockholm syndrome situation 😂
OK, I've added the proposed text in #3286, but this should wait on AnneK to comment before merging. I read the spec as you do @sideshowbarker but there is a LOT of chat around this in various issues, and I'd like to confirm before we modify docs and update BCD.
The Fetch doesn’t make anything easy. I feel like my relationship with has become a kind of Stockholm syndrome situation
I just want to say I appreciate the work, though: MDN is the best resource online for finding quasi-authoritative but understandably presented info on this topi.
@JamesTheAwesomeDude There's certainly a lot to be said for human-readable docs :-). I'm not sure whether I pity the people going deeply into spec interpretation or browser-compatibility more - both are clearly mad!
Fixed by linked PR
Most helpful comment
@JamesTheAwesomeDude There's certainly a lot to be said for human-readable docs :-). I'm not sure whether I pity the people going deeply into spec interpretation or browser-compatibility more - both are clearly mad!