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

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

From: Ilya Grigorik <igrigorik@google.com>
Date: Tue, 7 Jul 2015 14:26:14 -0700
Message-ID: <CADXXVKpm75Z9PzsYXnCRCg_5AxkavVmbsX-fZzMEyH0dFMgLVQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mike West <mkwst@google.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Richard Barnes <rbarnes@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Jun 30, 2015 at 12: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.

My point here was that "Vary" is a blunt instrument. When you tell the
cache to Vary on "Prefer"... per spec, the cache simply takes the full
value of said header and makes it part of its cache key. As such, if you
have multiple values in the same header, then you have unnecessary
fragmentation; this is not an issue if you have a dedicated header per

To say that "caches must account for this" when the spec (and existing
implementations) say precisely otherwise.. is not a great route. On a
related note, this is why I keep pushing for Key:

On Wed, Jul 1, 2015 at 9:47 AM, Martin Thomson <martin.thomson@gmail.com>

> `Prefer: https` seems about right; we should not over-optimize this.

+1 for separate header. This resolves the Vary issue.

Received on Tuesday, 7 July 2015 21:27:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC