This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We cannot set it to a Document object is the Document object can change due to navigation. Same issue as we had before. *sigh* So we should set it to the document's address I think, but with a number of complicated exceptions.
Turns out that navigating might nuke the request altogether and prevent new requests so maybe this is not an issue.
If it's really not an issue then we should close this.. but is it? What if you use history.pushState() to change the document's URL? I guess the pushState()-generated URL is relevant enough to use as document.referrer. (As for navigation - I certainly think that navigation should just terminate any requests, so this should not be a problem)
Well there's definitely an issue here between XMLHttpRequest and Fetch.
"an issue" - let's elaborate a bit to try to figure out what the issue is, might help us resolve it.. Definition of "referrer source" (HTML5) http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#referrer-source "A referrer source is either a Document or a URL." Algorithm for setting referer header (Fetch) http://fetch.spec.whatwg.org/#determine-referrer This algorithm doesn't cover anything XHR-specific (which is fine if the XHR spec sets "referrer source" explicitly). Does it? Yes: open() step 2.4 says "Set referrer source to document." But then there's send() step 10 which says request should be initialized with (among other things) referrer referrer source and this is marked as an open issue. So it seems either we have to 1) be able to pass a referrer source with the request and have Fetch do the right thing, or 2) reference the determine-referrer algorithm at this point and say something like referrer the result of calling the [determine referrer algorithm] for the given referrer source with the stuff in brackets appropriately linked. I'd suggest doing #1 - change http://fetch.spec.whatwg.org/#concept-request to say the request has an associated referrer or referrer source. It seems less work overall if we don't have to reference the determine-referrer algorithm from lots of other specs all over the place. Then we just drop the "pending issue" from the XHR spec and resolve this bug. How does it sound?
If you move it to Fetch you need to pass fetch a document. However, given that fetching happens in its own world (that can be its own thread) that does not really work. We did consider passing a document to fetch and using it for a number of things and leaving the separate thread thing as an application detail. However, it becomes observable if certain attributes of the document are modified and therefore it really is better to have this all sorted in advance. It's not entirely clear to me what the best way of solving this is. Probably need to better understand how the various pieces fit together first.
OK - if we don't want to pass document references to Fetch, why is there an algorithm in Fetch that deals with documents and "navigating"? Seems you might get the architecture right if you make your mind up here :-) IMO it makes sense to avoid passing documents to Fetch, so I suggest 1) Moving the #determine-referrer to the HTML spec (the part that deals with navigation, wherever that part is) and let the input to Fetch be an URL. 2) Resolve the issue in XHR by simply saying referrer URL of [referrer source]
Because that is legacy as said at the start of that section and will go away over time? Your suggestion is wrong for workers, but yes, something like that is probably what needs to be done. The other thing that is a bit weird about the current setup is that we provide a generic way to override headers but also special case paths for Referer and Origin. Feels kind of weird.
Workers should work fine with my suggestion - see open() step 3.3 of algorithm.
No, because in that case referrer source is a URL and a URL of a URL is a segfault.
Is it? The referrer source of a worker seems to be defined in step 4 here: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#processing-model-7 and the definition reads "using the responsible document specified by settings object as the referrer source" So unless I'm missing some extra processing step here it should not segfault.. (The link in XHR spec's open() step 3.3 seems broken by the way. Clicking "script's referrer source" goes to an #anchor that doesn't exist in that page anymore)
See bug 23780. Things changed around recently and might change more. So none of this is stable really...
https://github.com/whatwg/xhr/commit/1898f6f8981e8f926dc42392c07137eeedf7094b