Re: Include Referer-HTTP-header in requests from XMLHttpRequests

On 2006/06/29, at 11:08 AM, Mark Baker wrote:

>
> On 6/29/06, Subbu Allamaraju <subbu.allamaraju@gmail.com> wrote:
>> Even in the single domain case, there could be lots of apps and  
>> resources,
>> and the Referer header could be used for whatever use cases that  
>> this header
>> is used for non-XHR requests today.
>
> AFAIK, the main use case for Referer today is simply to find out who's
> linking to your site, which isn't relevant to single-domain.

Sure it is. My site might be of arbitrary complexity, and have many  
links to a single resource.


>> One use case is to find out the context
>> in which the request was generated for analytics purposes. It  
>> would be
>> useful to encourage browsers to send this header.
>
> I'm unconvinced.  I'm happy to leave the decision to implementors.

I'm not.

> I do note though, that Referer is listed as a request header that
> can't be set by a script, which seems unnecessarily restrictive to me.
> Maciej said[1] this was for in part for security reasons, but I don't
> think that's relevant in the single domain case.  I'd therefore be
> open to suggesting it be removed from that list, enabling authors to
> set it themselves.

I would be very much against that. Referer is very useful to Web  
sites that want to restrict casual linking into images and other  
resources. if XHR is able to change referers, and also eventually  
enables cross-site, it will become trivial circumvent this sort of  
protection (which, yes, isn't perfect, but is often good enough).

Right now, sites can trust that referers from browsers, at least,  
can't be manipulated. By changing that, you're reducing the  
information about the request context available to them.

Turn it around: What's the use case for changing it? Why is it so  
hard to send it?

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Thursday, 29 June 2006 18:29:32 UTC