- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 10 Mar 2015 15:42:26 -0700
- To: Brad Hill <hillbrad@gmail.com>
- Cc: Mike West <mkwst@google.com>, Ilya Grigorik <igrigorik@google.com>, 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>, Mark Nottingham <mnot@mnot.net>
Link: <https://equivalent/path>;rel="secure" Is probably OK. That means that you have the content from the body of the response, but you can follow the link to find a secure version. Then you only have to worry about minimizing the unsecured junk you are using to base decisions on. On 10 March 2015 at 14:10, Brad Hill <hillbrad@gmail.com> wrote: > 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/` >>> 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 22:42:53 UTC