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

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

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 8 Jul 2015 10:46:04 +0200
Message-ID: <CA+eFz_LhzD-1vJ-6ZvPZC_wHdxVTkf-5uPqmWCKJr_V_k2No6A@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Ilya Grigorik <igrigorik@google.com>, Martin Thomson <martin.thomson@gmail.com>, Mike West <mkwst@google.com>, Anne van Kesteren <annevk@annevk.nl>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
+1 for separate header. Seems to be the simplest and cleanest solution with
least side effects.

 Choice of header name was the main issue (root cause of the Chromium bugs)
so this should be something that is unlikely to clash.



On 8 July 2015 at 01:56, Richard Barnes <rbarnes@mozilla.com> wrote:

>
>
> On Tue, Jul 7, 2015 at 7:53 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>>
>>
>> On Tue, Jul 7, 2015 at 4:39 PM, Richard Barnes <rbarnes@mozilla.com>
>> wrote:
>>
>>>
>>>
>>> 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.
>>>
>>
>> I don't think that's true. Looking at the defined directives in [1] we
>> have things like "wait" which may be changed without affecting the response.
>>
>> Prefer: https, wait=120
>> Prefer: https, wait=119
>>
>> The above would create two different cache entries. Combine that with
>> handling=strict and we have yet more unnecessary variants. Hence my
>> recommendation to use separate headers.
>>
>>
>>>  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?
>>>
>>
>> Yes they will have to specify: "Vary: Upgrade-Insecure, ...,
>> other-cache-key-headers".
>>
>
> Ah, OK.  I see.  Given that, I can agree that a separate header makes
> sense.
>
>
>>
>> ig
>>
>
>
Received on Wednesday, 8 July 2015 08:46:35 UTC

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