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: Wed, 8 Jul 2015 21:44:09 -0700
Message-ID: <4614390021667766751@unknownmsgid>
To: Mike West <mkwst@google.com>
Cc: Tanvi Vyas <tanvi@mozilla.com>, Brian Smith <brian@briansmith.org>, Martin Thomson <martin.thomson@gmail.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>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>
Sent from my iPhone.  Please excuse brevity.

On Jul 8, 2015, at 21:23, Mike West <mkwst@google.com> wrote:

I'm looking at the spec again, and "insecure" -> "non-secure" is a slightly
more sweeping change than I expected, given that we use the term in one way
or another in practically every webappsec spec. How strongly do you folks
(Brian, Martin, Richard) feel about the distinction? :)


If the web can live with "Referer", it can live with this.  But it seems
roughly the same order of magnitude.  It makes me "sic" :)



-mike


--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Thu, Jul 9, 2015 at 12:06 AM, Richard Barnes <rbarnes@mozilla.com> wrote:

> On Wed, Jul 8, 2015 at 2:56 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:
>
>>  Firefox's implementation is about to land, so if we are changing
>> directive names it would be nice to know sooner than later.  Has Chrome's
>> already landed?  I don't want user agents to have to maintain support for
>> both upgrade-insecure-requests and upgrade-insecure directives.
>>
>
> "upgrade-non-secure", I thought.
>
>
>>
>>
>> On 7/8/15 11:12 AM, Mike West wrote:
>>
>> Ok. If no one strenuously objects by the time I wake up, I'll poke at the
>> spec with `upgrade-non-secure` in mind tomorrow.
>>
>>  -mike
>>
>>   --
>> Mike West <mkwst@google.com>, @mikewest
>>
>> Google Germany GmbH, Dienerstrasse 12, 80331 München,
>> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
>> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
>> Flores
>> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>>
>> On Wed, Jul 8, 2015 at 7:53 PM, Richard Barnes <rbarnes@mozilla.com>
>> wrote:
>>
>>>
>>>
>>>  On Wed, Jul 8, 2015 at 10:48 AM, Brian Smith <brian@briansmith.org>
>>> wrote:
>>>
>>>>   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.
>>>>
>>>
>>>   WFM
>>>
>>>
>>>>
>>>>  Cheers,
>>>> Brian
>>>>
>>>
>>>
>>
>>
>
Received on Thursday, 9 July 2015 04:44:41 UTC

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