- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 09 Apr 2006 07:22:26 -0700
- To: Jim Ley <jim@jibbering.com>
- Cc: public-webapi@w3.org
>> This would probably be helped by restricting to same-origin policies. >> But I'd like to have good usecases even for adding that. I think site >> authors would be upset if they couldn't rely on referer (which >> arguably already is an issue since some firewall produces block >> outbound referer headers). > > There's no arguably about it, many firewall's block it, as do others to > anonymise user activity through the web, such things cannot be relied > on. I also don't see the author use cases for shopping cart checks? > Surely these use cookie based state methods. Cookie based solutions won't work since cookies are sent with XHR. So to the site it'll look like this was a real request. What sites should do is to stick a random value in each form request and use that to authenticate each form transaction. However I believe many sites does not do that. > Site authors already cannot rely on referrer, so quite why they should > be able to rely on it with XHR I don't know, forcing special behavior on > UA's depending on where a request comes from seems to be something you > should do only in the most extreme situation. Saying that referrer can't be overriden isn't really 'forcing special behaviour'. The header is usually sent with every other request the UA does without giving control to the page of its value. / Jonas
Received on Sunday, 9 April 2006 14:22:29 UTC