On Wed, Mar 11, 2015 at 9:33 AM, Mike West <mkwst@google.com> wrote:
> On Wed, Mar 11, 2015 at 5:20 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>> Sure, but the UA automatically makes this decision on users behalf each
>> time, so effectively it is a conditional server redirect, but with a whole
>> bunch of gotchas:
>>
>
>
>> the server has to render full (200) response in case the client is not
>> "capable"
>>
>
> This isn't unique to my proposal. Your proposal has the same drawback, as
> the server doesn't know whether the client is capable until it opts-in to
> receiving the signal. That has the additional drawback of keeping the user
> on an insecure connection until the next navigation, and triggering all the
> associated insecure resource requests.
>
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.
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.
> 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.. We're talking
about a tradeoff of https on second visit VS. sending a header on every
outbound request.. personally, I prefer the opt-in route with https on
second visit.
ig