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

Re: [UPGRADE]: What's left?

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 10 Mar 2015 21:10:25 +0000
Message-ID: <CAEeYn8iupiCZvGTJpCRKiv0_M80FFEPS=kQxBxFLNc1QYJ+3Yg@mail.gmail.com>
To: Mike West <mkwst@google.com>, Ilya Grigorik <igrigorik@google.com>
Cc: Eric Mill <eric@konklone.com>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Yves Lafon <ylafon@w3.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>, Yoav Weiss <yoav@yoav.ws>, Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>
Totally insane here, and I'm sure it would break all kinds of tools that
look for literal "200" vs /2\d\d/, but could we create a new HTTP status
code, 243 or whatever, that means "OK, and this resource also available
over https"?

On Tue, Mar 10, 2015 at 12:44 PM Mike West <mkwst@google.com> wrote:

> On Tue, Mar 10, 2015 at 7:18 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>>
>> Yikes. This means that a 200 is now interpreted as a 302, which is
>> breaking a lot of HTTP semantics... I'll defer to Martin and Mark on this,
>> but it doesn't smell right.
>>
>
> I don't see this as being terribly controversial, but I'll defer to HTTP
> experts.
>
> In my mind, the 200 response indicates that the server was able to
> correctly serve a response for the request. That response contains data
> that triggers a navigation to a different page. This isn't substantially
> different from a JavaScript-driven `window.location` change; we just speed
> it up because we don't have to parse the page before navigating. It's no
> different, really, than `Refresh: ...` (not that `Refresh` is a model of
> sanity, of course).
>
> Do we absolutely have to invoke the upgrade on initial navigation request?
>> The proposed redirect dance breaks HTTP semantics and is bound to confuse
>> people + tooling.
>>
>
> No. It would be nice if we could upgrade immediately, but I don't think
> waiting until the second request is off the table.
>
>
>> Alternatively, if the site simply provided a meta opt-in tag and the UA
>> would remember this opt-in.. we would avoid these complications and
>> dramatically simplify this entire flow?
>>
>
> Pinning an opt-in that unlocks sending the header doesn't seem to me to be
> dramatically simpler. It just moves the complexity.
>
>
>> Concretely it would be something like:
>>
>> 1. User requests `http://example.com/` <http://example.com/>
>> 2. Server (http://) response includes upgrade opt-in (header or meta -
>> e.g. "Accept-CH: upgrade")
>> 3. (Optionally) User agent can immediately upgrade subresource requests
>> to https:// after processing the opt-in
>> 4. User agent remembers opt-in and advertises "Prefer: upgrade", or some
>> such, on future requests (nav and resources) to same origin
>>   a) Site can redirect the user to HTTPS (via 3XX) based on presence of
>> "prefer: upgrade"
>>   b) Site can lock-in the user into HTTPS (to avoid further 3XX overhead)
>> via HSTS based on presence of "prefer: upgrade"
>>
>
> This would probably work for the positive case (HTTP -> HTTPS). It's not
> clear that it would work for the negative case (HTTPS -> HTTP). In the
> former, we could certainly skip the first pageload, get the opt-in, and
> keep it for subsequent loads. For the latter, it's not clear how we'd
> distinguish between an initial load and a subsequent load for legacy user
> agents.
>
> -mike
>
Received on Tuesday, 10 March 2015 21:10:53 UTC

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