W3C home > Mailing lists > Public > public-webapi@w3.org > June 2006

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

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 29 Jun 2006 12:39:00 -0700
Message-Id: <27561497-3423-4BCC-BCB2-65B5F02537E4@yahoo-inc.com>
Cc: "Subbu Allamaraju" <subbu.allamaraju@gmail.com>, public-webapi@w3.org
To: "Mark Baker" <distobj@acm.org>

On 2006/06/29, at 12:24 PM, Mark Baker wrote:

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

Let's say I publish some content that I only want consumed by XHR  
that's sourced from my site. Sure, somebody can fake that request if  
they have control of the client, but I'm not looking for that level  
of control.

If I can't trust XHR to send a referer, I have to allow all requests,  
and that means that -- today -- somebody can link to that content  
from another site using <a>, <script>, <object>, etc.

Again, it isn't perfect; it's just a useful mechanism that's  
sometimes good enough (or at least better than nothing).

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

AFAIK the only browser that doesn't is Mozilla, and they're on track  
to adding it soon.

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

Maybe we should get rid of that pesky Request-URI too, and move to a  
fixed-length object identifier... ;)

Mark Nottingham
Received on Thursday, 29 June 2006 19:40:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC