W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: UPGRADE: 'HTTPS' header causing compatibility issues.

From: Brian Smith <brian@briansmith.org>
Date: Tue, 7 Jul 2015 13:58:15 -0400
Message-ID: <CAFewVt6bPYPnF=yUYfYVZMA2X0=rFHQU0QYQubN4oYrrK3k+3g@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Yoav Weiss <yoav@yoav.ws>, Richard Barnes <rbarnes@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>, Adrian Hope-Bailie <adrian@hopebailie.com>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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

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

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


Received on Tuesday, 7 July 2015 17:58:43 UTC

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