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

Mark,

On 6/29/06, Mark Nottingham <mnot@yahoo-inc.com> wrote:
> > 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.

I meant "who" as in "authority", not URI.

I have a script that scans my referer log for me, and its first job is
to filter out every referer URL from my own domain.  I'm sure there
are people for whom it's useful information, but I doubt that's the
80% case.

> > 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).

I agree, but that's for cross-domain, which is a very different
problem.  I agree that Referer is of higher value in cross-domain
scenarios.

> 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.

Right, but I don't think that matters much in the single domain case
since the author controls much of the request context.

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

AIUI, current practice is not to send the Referer header.

It's not hard to send, of course.  It's just a long string (commonly)
that doesn't add much value in the single domain case, IMO, but would
increase latency in the general case.  Not a good tradeoff, IMO.
Anyhow, whether it's a good tradeoff or not isn't my call, it's the
implementors' (or the authors', if we can permit it to be set via
setRequestHeader), so as I say, I'm happy to let them make it.

Mark.

Received on Thursday, 29 June 2006 19:24:37 UTC