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

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

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.



> 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 :)
>>
>
> I am totally going to use exactly this claim if/when I ever get around to
> rekindling the origin cookie discussion, where I'm pretty sure you argued
> exactly the opposite. :)
>

Conveniently, I have no recollection of that discussion!



>  For h2 users, there should be no need to use this thing
>>
>
> Why not? I suspect mixed content will still exist for folks who migrate to
> HTTP/2.
>

Do we agree that this header is not useful for HTTPS-schemed requests?

Aside from OE (which is like h2c in this regard), all h2 requests are HTTPS
requests.

--Richard



>
> -mike
>