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