- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 11 Sep 2012 23:44:42 -0700
- 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