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

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

From: Yoav Weiss <yoav@yoav.ws>
Date: Tue, 7 Jul 2015 21:28:44 +0100
Message-ID: <CACj=BEjrPXwV7pJZ6CH1M5x+=eadMKDBdgT2p+1JXhh9cVnLnQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Richard Barnes <rbarnes@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>, Adrian Hope-Bailie <adrian@hopebailie.com>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Jul 7, 2015 at 1:10 PM, Mike West <mkwst@google.com> wrote:

> On Wed, Jul 1, 2015 at 11:03 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>> 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"?
> It sounds like there's general agreement that `Prefer` is the right
> semantic to use here, but there's concern (and disagreement) about whether
> or not the caching impact a) exists, b) overrides the semantic value.
> If there's a clear solution for the caching problem (`key`), and we're
> just waiting for it to be deployed, then I'd prefer `Prefer`. :)
> Is that a crazy stance? Are there sincere impacts to the Internets that
> I'm missing? If not, I'll update the spec to `Prefer: secure-transport`.
Fair enough. Again, as long as the values of prefer are static per UA, the
caching damage is not huge, even without `key` (which isn't right around
the corner).

Out of curiosity, what other "Prefer" request header values are UAs sending?
Received on Tuesday, 7 July 2015 20:29:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC