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

I still think that `Prefer:` is the right semantic, but Brian's argument
that processing a new header is trivial in comparison to regexing one's way
through a `Prefer` block is completely convincing.

`upgrade-insecure-requests: 1`, going once, going twice...

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Jul 8, 2015 at 10:46 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

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