- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 1 Jul 2015 09:47:39 -0700
- 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