W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 1 Jul 2015 09:47:39 -0700
Message-ID: <CABkgnnWdJutiJXeUWuLoc5pj__eeH-=zEvh3+GtugSTy=_4q9A@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Richard Barnes <rbarnes@mozilla.com>, Ilya Grigorik <igrigorik@google.com>, Anne van Kesteren <annevk@annevk.nl>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 1 July 2015 at 06:31, Mike West <mkwst@google.com> wrote:
> On Wed, Jul 1, 2015 at 2:41 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>>
>> I suggest "Prefer: Transport-Security" as that is effectively what the
>> client is asking for.
>
>
> If `Vary` isn't an issue, then yes, something like this seems totally
> reasonable

Well, `Vary` is always relevant when you change your behaviour based
on the request contents.  However, the harm is contained by adding
`Vary: prefer`.  Or, as Adrian suggests, making that request unique.
(Vary is arguably superior here because a shared cache won't
invalidate stored responses for requests without the flag; but I've
heard of shared cache bugs that might suggest that `Cache-Control` is
sensible.)

If instead you refer to the loss of signal inherent in the `Prefer`
header field when there are multiple directives with different vary
behaviour, then I sympathize; it's why I have a slight bias toward new
header fields when caching characteristics are important.  This case
doesn't seem like a high-runner for that treatment though.  We don't
see a lot of prefer use in the case this aims to address.

`Prefer: https` seems about right; we should not over-optimize this.
Received on Wednesday, 1 July 2015 16:48:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC