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

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
>