- From: David Bruant <bruant.d@gmail.com>
- Date: Fri, 07 Feb 2014 16:18:13 +0100
- To: Mike West <mkwst@google.com>, Adam Barth <w3c@adambarth.com>
- CC: Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Le 07/02/2014 15:07, Mike West a écrit : > +Adam > > Hey David! > > One the one hand, I agree with you that the current spec combines two > aspects into a single keyword. On the other, I agree with Adam of 2011 > that some of the combinations don't make much sense. I'd like to keep > things simple, and I hope we can do that by addressing your use-case, > but sticking to the single-keyword model. I came to agree with Adam in 2011 and still do. I just wanted to provide a background as complete as possible and lay down our options. > How about something like this hastily considered list? > > none => no referrer header for any request (today's "none") I think that some websites break if sent no Referer header, but survive to a Referer set to the empty string. But I forgot where I read that. Does it ring a bell to someone? Maybe that was Accept... > none-when-insecure => no referrer header for HTTPS->HTTP (today's > "default") > origin-always => always send a referrer header containing only the > origin (today's "origin") > origin-when-cross-origin => full referrer header for same-origin > requests, origin referrer header for cross-origin requests > unsafe-url-always => full referrer header for any request (today's > "always") > > Bikeshedding welcome... Looks good to me. I like the "unsafe-" for the last one as it suggests an additional danger or at least something to look into. David
Received on Friday, 7 February 2014 15:18:44 UTC