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

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

From: Richard Barnes <rbarnes@mozilla.com>
Date: Tue, 30 Jun 2015 10:26:38 -0400
Message-ID: <CAOAcki9r9HOeMKKtuXqkwpD5Sbk0MrtYRMZYeZ20atH5gX7w4A@mail.gmail.com>
To: Mike West <mkwst@google.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 9:28 AM, Mike West <mkwst@google.com> wrote:

> 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).

If you happen to have a pointer handy, I would be interested to take a look
at the history here.

It does seem like Supported is different from Prefer.  It's more like
Accept -- it's OK if you send me content that depends on $FEATURE.

> 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.`

Adding header bloat to HTTP/1.1 seems like a feature, not a bug :)  For h2
users, there should be no need to use this thing, and for the poor souls
doing h2c, HPACK.

Received on Tuesday, 30 June 2015 14:27:06 UTC

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