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

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.
   https://bugzilla.mozilla.org/show_bug.cgi?id=170477

> 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
mnot@yahoo-inc.com

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