W3C home > Mailing lists > Public > public-webapi@w3.org > July 2007

Re: [xhr] cross site proposal headers

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 26 Jul 2007 16:44:11 -0700
Message-ID: <46A931CB.6050408@sicking.cc>
To: Anne van Kesteren <annevk@opera.com>
CC: Web APIs WG <public-webapi@w3.org>

Anne van Kesteren wrote:
> On Mon, 23 Jul 2007 10:35:27 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>> A couple of questions regarding the cross-site XHR proposal:
>> http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
>> As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest 
>> cross-site requests should alway have the headers set through 
>> setRequestHeader removed. This includes requests done after a redirect 
>> to a different server.
>> Why prevent a user from setting the "Content-Access-Control" header? 
>> That is generally a response header and I'd expect servers to ignore it.
> If requests with arbitrary headers set can harm a server they are 
> already vulnerable. Is it really wise to restrict this?

I'm arguing for allowing the header to be set, as no server has any 
reason to pay attention to it.

>> What is the purpose of the Referer-Root header? Why can't sites rely 
>> on the Referer header?
> Isn't Referer disabled by some third-party software now and then? Such 
> as antivirus software? Another reason is probably that Referer-Root 
> contains the exact format needed for the access check. We could use that 
> in the access-control document probably.

This seems like a loosing battle that I don't see a reason to fight. If 
the user (by installing software or through corporate policies) disables 
the Referer header, why should we try to circumvent them? That seems 
just likely to piss them off and then add Referer-Root to their blocking 

If the sites want to use the Referer header and it has been blocked the 
site can simply deny the request. Non-idea for the end-user, but by 
their own choice.

/ Jonas
Received on Thursday, 26 July 2007 23:45:03 UTC

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