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

+1 for using "Prefer" header however using "Prefer:
upgrade-insecure-requests" only deals with the scenario when the server
will return a CSP header of upgrade-insecure-requests. What about the
scenario where the server will respond with an STS header?

I suggest "Prefer: Transport-Security" as that is effectively what the
client is asking for.

WRT caching, it seems to me that a server that supports the upgrade will do
a redirect when it first receives this header and should simply use
Cache-Control : no-store in the redirect response and never use the Vary
header anyway. It's likely that in the upgrade scenario this flow will only
happen once per client and so the value of caching this step is low.

Also, not sure why it's critical to drop a few bytes from the headers at
the expense of making this understandable?



On 30 June 2015 at 21:36, Richard Barnes <rbarnes@mozilla.com> wrote:

>
>
> On Tue, Jun 30, 2015 at 3: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.
>>
>>
>>> 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!
>>>
>>
>> It might have been Martin, now that I think of it. Or Mark.
>>
>> No matter, it's a good argument, and I agree with it!
>>
>>
>>>  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?
>>>
>>
>> We do not. If a site relies on this feature to avoid mixed content, it
>> may wish to downgrade unsupporting UAs to HTTP. They can't do that unless
>> they know a priori whether or not the UA supports the feature.
>>
>
> I see.  So back to the other argument: HPACK :)
>
>
>>
>> -mike
>>
>
>