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.
> the client incurs the cost of downloading said response (at a minimum some
> of it, most likely all of it)
>
Again, non-unique. Note also that the opt-in mechanism would also require
_rendering_ all of this, which is even slower. :)
> the perf+timing specs now have to account for completely new type of
> redirect
>
Is this really completely new? Those specs need to account for oddities
like `Refresh: 0;url=https://example.com/` and navigation cancellations due
to `X-Frame-Options` already, don't they?
> crawlers need to be updated to account for this signal
>
I'm not convinced that this is the case; we're talking about authors who
are explicitly _not_ migrating everyone to HTTPS, but are keeping HTTP up
and running with this upgrade mechanism as an optimistic redirect for
capable clients. I don't think they'd _want_ to be advertising HTTPS
support until they didn't need the upgrade mechanism anymore.
> ... all because we're overloading 200 with redirect semantics, which is
> really painful. I'd *much* prefer if we retain the current 3XX flow, which
> would make all of this transparent to existing tools and implementations.
>
It trades complexity in the areas you've outlined for complexity in the
author's stack (as anecdotally outlined with the static site example in the
email you're responding to). I'm not yet convinced that that's a tradeoff
worth making.
-mike
--
Mike West <mkwst@google.com>, @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)