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

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

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 12 Sep 2012 13:13:50 -0700
Message-ID: <CAJE5ia-TSZVySXZ8ANKj5RsUhfG1gC1NJxcZoKVp8e7UicGnkw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@annevk.nl>, Webapps WG <public-webapps@w3.org>
I certainly agree that we should define these things clearly.  :)


On Tue, Sep 11, 2012 at 11:44 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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 20:14:50 UTC

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