W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2014

Re: referrer directive expressiveness

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 07 Feb 2014 16:18:13 +0100
Message-ID: <52F4F935.7080501@gmail.com>
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.

Received on Friday, 7 February 2014 15:18:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC