- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 12 Sep 2012 13:13:50 -0700
- 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. :) 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