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

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

From: Richard Barnes <rbarnes@mozilla.com>
Date: Tue, 7 Jul 2015 19:39:07 -0400
Message-ID: <CAOAcki8Pw8M_AErAQs9FK+iDBAdQ5QdwjJFhnKc77NGdMFFhEg@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mike West <mkwst@google.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Anne van Kesteren <annevk@annevk.nl>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Jul 7, 2015 at 5:26 PM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> 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
> value.
>
> 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:
> https://tools.ietf.org/html/draft-fielding-http-key-02
>
> On Wed, Jul 1, 2015 at 9:47 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> `Prefer: https` seems about right; we should not over-optimize this.
>
>
> +1 for separate header. This resolves the Vary issue.
>

I'm confused.  Any way we do this, it will cause the content to be
(potentially) different, requiring the cache to store different things.

If your concern with Prefer that people tend to put Prefer in Vary,
wouldn't they have to put Upgrade-Insecure in Vary as well?

--Richard


>
> ig
>
>
Received on Tuesday, 7 July 2015 23:39:36 UTC

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