On Tue, Jul 7, 2015 at 8:10 AM, Mike West <mkwst@google.com> wrote: > It sounds like there's general agreement that `Prefer` is the right > semantic to use here, but there's concern (and disagreement) about whether > or not the caching impact a) exists, b) overrides the semantic value. > FWIW, I agree with Richard Barnes that it is better to indicate exactly what you intend to indicate, instead of something more vague. In particular, if the ultimate effect of the header is to tell the server that upgrade-insecure-requests is supported, then a name like "upgrade-insecure-requests" should be used. As for "Prefer: upgrade-insecure-requests" vs "upgrade-insecure-requests: 1", I prefer the latter because it is easier to process at every level. A lot of web server configuration tools and request routing frameworks are not so good at making it easy to *correctly* tokenize structured header fields such as the comma-separated ones. In particular, tools are often inconsistent at canonicalizing comma-separated header fields like Prefer (e.g. combining two Prefer header fields into a comma-separated list before passing to the routing/rewrite engine). I expect that many people would use these simplistic configuration tools to implement upgrade-insecure-requests, so optimizing for that seems useful. In particular, the rules for redirecting to HTTPS using mod_rewrite would be simple for a separate header field but much more complicated for Prefer, AFAICT, particularly if one wanted to pendantically match "unpgrade-insecure-requests" but not "upgrade-insecure-requests-or-whatever". Also note that there's no semantic advantage to combining multiple values into a Prefer header field, so using it seems to add complication for no gain. So, I vote for "upgrade-insecure-requests: 1" or (ideally, but probably unpopularly) "upgrade-non-secure-requests: 1". Regarding insecure vs non-secure, see also [1] and [2] and [3] and the old Microsoft Manual of Style, which says "Do not use 'insecure' to mean 'not secure'." Cheers, Brian [1] http://itknowledgeexchange.techtarget.com/writing-for-business/is-that-network-insecure-or-unsecure/ [2] https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure [3] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
Received on Tuesday, 7 July 2015 17:58:43 UTC