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

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.

Adam


On Tue, Sep 11, 2012 at 5:48 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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 05:44:52 UTC