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 21:00:49 +0200
Message-ID: <CAKXHy=e7TskdnYAjsmhnAQXfFvMij4QkAaHhbGwo7p7jcm0xsA@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 4:26 PM, Richard Barnes <rbarnes@mozilla.com> wrote:
>
> If you happen to have a pointer handy, I would be interested to take a
> look at the history here.
>

https://github.com/w3c/webappsec/issues/216


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

I'll defer to people who know things about caching, but it seems like it
would end up in the same bucket as `Prefer` if it's possible to have more
than one supported value.


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

I am totally going to use exactly this claim if/when I ever get around to
rekindling the origin cookie discussion, where I'm pretty sure you argued
exactly the opposite. :)


>  For h2 users, there should be no need to use this thing
>

Why not? I suspect mixed content will still exist for folks who migrate to
HTTP/2.

-mike
Received on Tuesday, 30 June 2015 19:01:38 UTC

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