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

On Tue, Jun 30, 2015 at 8:24 PM, Richard Barnes <rbarnes@mozilla.com> wrote:

>
>
> On Tue, Jun 30, 2015 at 3:00 PM, Mike West <mkwst@google.com> wrote:
>
>> On Tue, Jun 30, 2015 at 4:26 PM, Richard Barnes <rbarnes@mozilla.com>
>> wrote:
>>>
>>> If you happen to have a pointer handy, I would be interested to take a
>>> look at the history here.
>>>
>>
>> https://github.com/w3c/webappsec/issues/216
>>
>>
>>> It does seem like Supported is different from Prefer.  It's more like
>>> Accept -- it's OK if you send me content that depends on $FEATURE.
>>>
>>
>> I'll defer to people who know things about caching, but it seems like it
>> would end up in the same bucket as `Prefer` if it's possible to have more
>> than one supported value.
>>
>
> 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."
> """
>

Care to elaborate how this assertion is wrong?


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

I hear that the Internet has cache servers as well :D

A static set of "Prefer" headers would mean that (very much like "Accept")
in case that content varies on `Prefer`, intermediate caches would have to
maintain ~ a copy per UA. The damage can be minimized if UAs coordinate to
make sure that similar `Prefer` values are *identical* between the
different UAs.

That's not *awful*, but in terms of caching, a separate header name is
better, at least until `key
<https://tools.ietf.org/html/draft-fielding-http-key-02>` becomes a thing.

Is "Upgrade-Insecure-Requests: yes pleasssssse" much worse than "Prefer:
upgrade-insecure-requests"?


>
> Given that, ISTM that "Prefer: upgrade-insecure-requests" is the right
> option here, or your favorite aesthetic variant thereof.
>
>
>
>> Still, this is a totally reasonable direction to move in. If we're fine
>>>> with the length, then why not `upgrade-insecure-requests: Totally
>>>> supported! Gimmie that HTTPS, please.`
>>>>
>>>
>>> Adding header bloat to HTTP/1.1 seems like a feature, not a bug :)
>>>
>>
Interesting approach... In any case, since we're talking about navigational
requests only, the extra ~20 bytes make very little real life difference.
(which wouldn't have been the case if we slapped those extra ~20 bytes on
*every* outgoing subresource request)

One might also argue that since we are talking only about navigational
requests, the caching argument becomes weaker since HTML content tends to
be dynamic and non-cacheable. (even though that may change with the magic
of Service Workers)