- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 26 Jul 2007 16:44:11 -0700
- 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 list. 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