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

Re: [UPGRADE]: What's left?

From: Mike West <mkwst@google.com>
Date: Tue, 10 Mar 2015 20:41:26 +0100
Message-ID: <CAKXHy=dRQKuEDr9mzHvOVha8SV8A1hiuXyUgAJFkzogfggccEw@mail.gmail.com>
To: 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>
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

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

Received on Tuesday, 10 March 2015 19:42:14 UTC

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