Bug 21264 - referrer source is wrong
referrer source is wrong
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: XHR
unspecified
PC All
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
:
Depends on: 23780
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-13 11:21 UTC by Anne
Modified: 2013-11-18 16:15 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2013-03-13 11:21:39 UTC
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.
Comment 1 Anne 2013-05-02 10:24:02 UTC
Turns out that navigating might nuke the request altogether and prevent new requests so maybe this is not an issue.
Comment 2 Hallvord R. M. Steen 2013-11-07 14:37:33 UTC
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)
Comment 3 Anne 2013-11-07 14:41:44 UTC
Well there's definitely an issue here between XMLHttpRequest and Fetch.
Comment 4 Hallvord R. M. Steen 2013-11-08 10:38:10 UTC
"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?
Comment 5 Anne 2013-11-08 22:37:43 UTC
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.
Comment 6 Hallvord R. M. Steen 2013-11-08 22:54:21 UTC
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]
Comment 7 Anne 2013-11-08 23:05:35 UTC
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.
Comment 8 Hallvord R. M. Steen 2013-11-09 01:03:50 UTC
Workers should work fine with my suggestion - see open() step 3.3 of algorithm.
Comment 9 Anne 2013-11-09 01:43:13 UTC
No, because in that case referrer source is a URL and a URL of a URL is a segfault.
Comment 10 Hallvord R. M. Steen 2013-11-09 21:38:28 UTC
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)
Comment 11 Anne 2013-11-11 01:22:49 UTC
See bug 23780. Things changed around recently and might change more. So none of this is stable really...