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

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

From: Mike West <mkwst@google.com>
Date: Tue, 30 Jun 2015 15:28:20 +0200
Message-ID: <CAKXHy=eds6ez+1n5Etmek0NbNxMNhSkdTU2wKOJmA0z+W-NJTA@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: 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, Jun 30, 2015 at 2:26 PM, Richard Barnes <rbarnes@mozilla.com> wrote:

> This seems worth a little bikeshed paint.
>

I'd like my lock to be neon green, please.


> I appreciate that "HTTPS" and "TLS" are short, but it seems like that
> comes at the cost of having any semantic content.  Without staring at the
> spec for a few minutes, I have no idea what these mean.
>

Totally agree. We ended up with "HTTPS" by allowing concerns regarding
number of bits on the wire to override those concerning clarity.

Is it accurate to say that the goal here for the UA to indicate that it
> supports upgrade-insecure-requests?  So that the server knows that it's
> safe to upgrade this client even if it relies on u-i-r to make HTTPS work
> without mixed content problems.
>

Yes.


> Perhaps we could borrow a page from SIP here [1], and use something like
> "Supported: upgrade-insecure-requests"?
>

An earlier version was an overly verbose `prefer` header, which Ilya shot
down due to caching concerns (e.g. `vary: prefer` would have bad results as
it's tied to the whole header value, as opposed to the specific preference).

Still, this is a totally reasonable direction to move in. If we're fine
with the length, then why not `upgrade-insecure-requests: Totally
supported! Gimmie that HTTPS, please.`

-mike
Received on Tuesday, 30 June 2015 13:29:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC