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

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".

ig