W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [XHR] What referrer to use when making requests

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 11 Sep 2012 23:44:42 -0700
Message-ID: <CA+c2ei9vzNTPV=ie+suynVkXLJGwc0oWSS28kg8qq_e5OJwVDQ@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>
Cc: Anne van Kesteren <annevk@annevk.nl>, Webapps WG <public-webapps@w3.org>
On Tue, Sep 11, 2012 at 10:43 PM, Adam Barth <w3c@adambarth.com> wrote:
> I'm sorry this thread has taken too long.  I've lost all context.  If
> you'd like to continue this discussion, we'll likely need to start
> again.
> My main reaction to what you've written is that Chromium's network
> stack is in an entirely separate process and we manage to implement
> these requirements without using global variables.  I'm not sure if
> that's at all relevant to the topic we were discussing.

Yeah, sorry I dropped the ball here.

My main concern is this:

It's currently generally poorly defined what the referer header is
supposed to be when running the fetch [1] algorithm.

For example, the spec says to use the "entry script"'s document when
the fetch happens in response to a "in response to a call to an API".
But it's very undefined what that includes.

For example removing an element from the DOM can cause a restyling to
happen, which can trigger a new CSS rule to apply which means that a
new background image is used which in turn means that a resource needs
to be fetch. This fetch is definitely happening "in response to a call
to an API", specifically the call to remove the element from the DOM.
Does that mean that we should use the document of the "entry script"
which called element.removeChild as the referrer? It seems much more
logical to use the URI of the stylesheet which included the rule

What's worse is that it might not even be the call to .removeChild
which is what's causing the fetch to happen since restyles are lazy.
So it might be a much later call to get an .offsetTop property which
causes the fetch to happen. I would think that from a web developers
point of view, using the "entry script" for background fetches
essentially means that the referrer is random.

Instead we should always use the URI of the stylesheet which linked to
the background, which doesn't match what any of the options in the
fetch algorithm currently calls for.

In general, there are currently very few places that I think should
fall into the category of "in response to a call to an API". Off the
top of my head it's just EventSource, XMLHttpRequest, Worker,
SharedWorker and importScripts. I'd rather explicitly define for them
what the referrer should be rather than using the ambigious catchall
"in response to a call to an API" rule.

Additionally, for at least importScripts there doesn't seem to be a
Document object we could use that would give us the correct referrer.
We should use the URI of the worker which called importScripts. The
same thing applies when EventSource, XMLHttpRequest, Worker or
SharedWorker is used inside a Worker or SharedWorker.

And for EventSource, XMLHttpRequest, Worker and SharedWorker I'd much
rather use the same Document or worker as is used for base-URI
resolution than the document of the "entry script".

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetching-resources

/ Jonas
Received on Wednesday, 12 September 2012 06:45:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC