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:28:11 +0200
Message-ID: <CAKXHy=cKz2BKTP0pVNuvwwOUw_82Ag+EgwpX0kCtMXgK+sLo-A@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>, Ilya Grigorik <igrigorik@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:24 PM, Richard Barnes <rbarnes@mozilla.com> wrote:
>
> Looking at the above discussion, it looks like Ilya's just wrong, in
> particular in this assertion:
>
> """
> Prefer: x,y,z" forces "x,y,z" to become part of the cache key, evne if x
> and y have no business of being part of the cache key."
> """
>
> We've already crossed that bridge -- there are some "Prefer" values that
> you want to be part of the cache key (return=minimal) and some that you
> don't (wait).  So caches already need to either take into account the
> contents of Prefer or accept the penalty of having irrelevant stuff in the
> key.  Note that for in-browser caches, the list of Prefer values is
> probably going to be static anyway, so this whole discussion is moot.
>
> Given that, ISTM that "Prefer: upgrade-insecure-requests" is the right
> option here, or your favorite aesthetic variant thereof.
>

+Ilya, who I would dearly love to be wrong, as `Prefer` seems like the
right thing to do.


> 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. :)
>>
>
> Conveniently, I have no recollection of that discussion!
>

It might have been Martin, now that I think of it. Or Mark.

No matter, it's a good argument, and I agree with it!


>  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.
>>
>
> Do we agree that this header is not useful for HTTPS-schemed requests?
>

We do not. If a site relies on this feature to avoid mixed content, it may
wish to downgrade unsupporting UAs to HTTP. They can't do that unless they
know a priori whether or not the UA supports the feature.

-mike
Received on Tuesday, 30 June 2015 19:28:59 UTC

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