- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 18 Jul 2011 23:02:09 +1200
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: ietf-http-wg@w3.org
On 18/07/11 19:05, Julian Reschke wrote: > On 2011-07-18 04:21, Amos Jeffries wrote: >> ... >> This MSIE handling of 301 is a big problem in some installations. To the >> point that they are migrating their customers away from MSIE just to get >> the Firefox/Chrome behaviour. >> ... > > How so? Why don't they fix their sites? Details, please. 301 - Portals enforcing policy of no unencrypted content past the border and bouncing the http:// requests to https:// at the gateway. They require all inbound http:// get redirected to https:// without bothering the user. Method remaining unchanged through the redirect. 301 is perfect here, as the domain is fixed and all http:// URLs are permanently redirected to their https:// exact equivalents. For MSIE this only works on POST. 307 - Portals doing policy agreements and splash pages. They require at minimum an arbitrary page of content to be visible to the user regardless of whether the request first made was a GET, CONNECT, POST etc. 307 seems to fit best until the 428 starts working on all requests. Preserving the method is important here. 3 months ago when I last saw this needed only Firefox and Chrome were doing 307 right. This is the first I've seen with MSIE on the good list there. >> ... >>> All that said, GET and POST are vastly more common for browsers to >>> handle than other methods. Having reasonable requirements for GET and >>> POST would be a welcome step forward. >>> >>> Adam >> >> Even just idempotent / non-idempotent separation would be great. That >> also leaves it open for consistency with future methods. >> ... > > That doesn't work, as given a new method name, you don't know whether > it's idempotent or not. Thats one of the things the new drafts require them to indicate now, with unknowns treated as non-idempotent by default. yes? AYJ
Received on Monday, 18 July 2011 11:02:51 UTC