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

I certainly agree that we should define these things clearly.  :)

Adam


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