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

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

From: Brian Smith <brian@briansmith.org>
Date: Wed, 8 Jul 2015 13:48:44 -0400
Message-ID: <CAFewVt78B9TSmqAtUm8cyaJSeqC1jTHDKuVDxuYp5UTZEwx8Tw@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mike West <mkwst@google.com>, Adrian Hope-Bailie <adrian@hopebailie.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 Wed, Jul 8, 2015 at 1:08 PM, Richard Barnes <rbarnes@mozilla.com> wrote:

> On Wed, Jul 8, 2015 at 9:29 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>> On 8 July 2015 at 07:53, Mike West <mkwst@google.com> wrote:
>> > `upgrade-insecure-requests: 1`, going once, going twice...
>> OK, I'll bite.  -requests seems unnecessarily verbose.  I mean, yes,
>> we do want to be precise and clear, but `upgrade-insecure` seems
>> enough; though only if you also change the CSP directive name I
>> suppose.
> Please, let's just have the header name match the directive name.

I agree it is better to have it match the directive name. However, I also
think it would be fine to rename the CSP directive to "upgrade-insecure" or
(better) "upgrade-non-secure".

Consider the case of ws:// to wss:// upgrade. No "requests" are involved.
Also, for HTTP -> HTTPS, the mechanism also indirectly upgrades the
responses. So "-requests" seems not so good irrespective of the HTTP header
field naming issue.

Received on Wednesday, 8 July 2015 17:49:12 UTC

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