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
>