- From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Date: Mon, 16 Mar 2015 02:26:17 -0400
- To: Ilya Grigorik <igrigorik@google.com>, Mike West <mkwst@google.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.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>
On Wed 2015-03-11 14:42:55 -0400, Ilya Grigorik 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. > > 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. The 200+implicit redirect case is only going to be implemented by sites that can't go ahead and do a 302 redirect to https in the first place. the oubound Prefer: on every http:// (and https://, if we want to signal safety for HSTS) has to be done by the client on *every* navigational request, even for sites that have already done a full migration. As a stepping stone, the 200+implicit redirect seems like something most parts of the web could get rid of eventually, whereas the Prefer: header on all outbound navigations seems like permanent cruft in the stack. --dkg
Received on Monday, 16 March 2015 06:27:37 UTC