On Wed, Mar 11, 2015 at 7:42 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> There is a difference. In the 200+implicit redirect case, presumably the
> UA wouldn't even render the content of http response, but it's still forced
> to download it, which means the user is incurring bytes without even being
> aware of it.
>
Correct. There's a performance impact, but I think it's one we could
mitigate by examining the headers as they come in, and canceling the
request if/when we see a CSP header containing the upgrade trigger. In
Chrome, I'd like to start doing this anyway in order to improve the
robustness of both `X-Frame-Options` and the `frame-ancestors` directive
(both of which we currently process in Blink after obtaining the majority
of the response).
> Between all the issues introduced by adding another redirect mechanism and
> forcing "Prefer" on all outbound http:// requests, I'd actually
> (reluctantly, but its "less worse" in my books) prefer the latter.. which
> would then trigger a 3XX and reuse existing concepts without breaking HTTP
> semantics, tooling, etc.
>
I don't understand the issues you're referring to (again, how do the tools
deal with `Refresh` today?), but I know you know this space better than I.
> Again, non-unique. Note also that the opt-in mechanism would also require
>> _rendering_ all of this, which is even slower. :)
>>
>
> Yes, but this seems like a micro-optimization.. Yes you don't get https://
> on "first" visit, but your first request is going out on http:// anyway
> so a MITM can downgrade you anyway, so we're not losing much..
>
That's a reasonable point. I agree that there's not much security benefit
to upgrade alone, as it can be trivially stripped. One more reason to
consider it a stepping stone in a migration path.
> personally, I prefer the opt-in route with https on second visit.
>
The opt-in is strange to me because the next step seems unambiguous; the
server says "Hey, do you support upgrades?", in the next request the client
responds "Yes, totally!", and the server responds with a redirect. There's
no other action the server can take as a result of the opt-in. It seems
strange to pretend that we don't know what the server is going to do, and
to wait for explicit confirmation of the redirect that's being implicitly
offered.
Also, note that this only addresses the HTTP->HTTPS use-cases. It doesn't
help us address downgrading incapable clients from HTTPS to HTTP to avoid
mixed content issues. I don't know how to do that cleanly without sending a
positive "upgrade-capable" signal of some sort along with requests.
-mike