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. igReceived on Wednesday, 11 March 2015 18:44:06 UTC
This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC