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 15:36:14 -0400
Message-ID: <CAOAcki-pPw=ThqCzPK16z_M-YKkUEs9g3ho35d86Rmp4q82PqQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Ilya Grigorik <igrigorik@google.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, Jun 30, 2015 at 3:28 PM, Mike West <mkwst@google.com> wrote:

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

I see.  So back to the other argument: HPACK :)


>
> -mike
>
Received on Tuesday, 30 June 2015 19:36:44 UTC

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