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 17:48:31 -0700
Message-ID: <CA+c2ei91F=JpJRg5NgORGaEvTf80kxsPxp1j8UWZvAv20oJjzA@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Webapps WG <public-webapps@w3.org>
On Sun, Jul 8, 2012 at 8:50 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Sun, Jul 8, 2012 at 3:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Sun, Jul 8, 2012 at 3:54 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> What is the reason for this? This seems less consistent than using the
>>> same document as we use for things like same-origin checks and
>>> resolving relative urls. In general, we've been trying to move away
>>> from using the "entry script" in Gecko for things since it basically
>>> amounts to using a global variable which tends to be a source of bugs
>>> and unexpected behavior.
>>
>> Really? All new APIs still use the entry script to determine origin,
>> base URL, and such. The reason is that HTML fetch works this way and
>> provides no overrides and last time we discussed this nobody thought
>> it was important enough to create an override just for XMLHttpRequest.
>
> When I researched this several years ago, this behavior was consistent
> across non-WebKit browsers, so I changed WebKit to match other
> browsers (and the spec).  The entry script is used fairly consistently
> throughout the platform to set the Referer.

Sorry about losing this thread.

The problem is that you can't always tell when a load is triggered by
a script vs. when it's triggered by something else. We do have what is
essentially a global variable which tracks the "entry script", but
once we are deep in the network code, we can't tell if this entry
script was what triggered the load, or if there's been enough things
happening higher up on the stack that we really can't consider the
script as the trigger any more.

This is of course the general problem with global variables, which is
what the "entry script" effectively is.

Consider for example the case if JS removes an element from the DOM.
This might cause a new set of selectors in a stylesheet to match,
causing an element to change background. Since backgrounds are loaded
lazily, we would at that time fire off the network request for the
background image. It doesn't seem right that the background should use
the "entry script" as the referrer. The stylesheet seems in this case
to be the more correct referrer.

Another problem that we have, which possibly is specific to Gecko, is
that various pieces of our platform is implemented in javascript. This
makes it harder to know that the "entry script" is always correct.

Hence I don't think we'll be able to use the "entry script" as the
referrer in general. We can of course still do it in selected cases,
but I generally think it's the wrong answer. For example in the case
of XHR it seems more consistent to use the same document as is used
for relative URL resolution.

/ Jonas
Received on Wednesday, 12 September 2012 00:49:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT