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

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

From: Richard Barnes <rbarnes@mozilla.com>
Date: Tue, 7 Jul 2015 13:34:45 -0400
Message-ID: <CAOAcki8nQxGb_Mn_KRneuac2QWba9YDaWR+CfjeH2eHrb309HA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Yoav Weiss <yoav@yoav.ws>, 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 8:10 AM, 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`.

I still feel like "secure-transport" doesn't accurately capture the
semantic you're after here.  I thought we were trying to say "It's safe to
upgrade me because I support upgrade-insecure-requests", with the emphasis
on the latter thing.  So maybe "secure-upgrade"?  (This is also why I would
prefer "Supported: upgrade-insecure" over "Prefer", but I'm not hard over
on that.)

(I know this sounds like bikeshedding, but it's important to get the
conceptual model right here.  Both to be clear in the spec, and to have a
clear path forward.)

Received on Tuesday, 7 July 2015 17:35:13 UTC

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