Re: #160: Redirects and non-GET methods

 On Sun, 17 Jul 2011 16:37:01 -0700, Adam Barth wrote:
> On Sun, Jul 17, 2011 at 4:16 AM, Mark Nottingham wrote:
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>
>>
>> I've just tested the latest iterations of the browsers, with the 
>> following results:
>>
>> • Safari/533.21.1 - all 301, 302, 307 rewritten to GET; 303 methods 
>> are preserved
>> • Firefox/5.0.1 - all 301, 302 rewritten to GET; 303 and 307 methods 
>> are preserved
>> • Chrome/14.0.814.0 - all 301, 302 rewritten to GET; 303 and 307 
>> methods are preserved
>> • Opera/11.50 - all 301, 302 rewritten to GET; 303 methods are 
>> preserved; 307 tests crash the browser
>> • MSIE/9.0 (latest) - all 301, 302 methods preserved except POST 
>> (changed to GET); all 303, 307 methods are preserved
>>
>> So, many browsers rewrite many methods to GET on 301 and 302. 
>> whereas most browsers preserve methods on 303 and 307*.
>>
>> We *could* codify this practice. However, as Julian notes in the 
>> bug, the fact that IE doesn't rewrite anything except POST is an 
>> existence proof (and a fairly large one) that it's workable to not 
>> rewrite the method on non-POST methods.

 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.

 While the proposed 428 status will help in most of these cases, the 
 browser hiding of 4xx reply entity on certain methods currently causes 
 more of a hindrance there than 301 does. The nasty hack at present is to 
 301 redirect to a location which does 428 on the followup GET.

>>
>> So, I'm inclined to agree that we could address this by changing 301 
>> an 302 to note that POST is rewritten to GET; it's a smaller change, 
>> although it would require changes in more browsers.
>>
>> Thoughts? Especially from browser people?
>
> w.r.t. Chrome's behavior, specifically, our intent was to match
> Firefox, which it looks like we've succeeded at.
>
>>From the table above, I would recommend that Safari change to not
> rewrite 307 because that seems to both violate the intent of 307 and
> to align better with other user agents.  With that change (modulo
> crashes!), all the non-IE browsers would behave the same way, which 
> is
> a collectively stable equilibrium that I wouldn't recommend
> disrupting.
>
> 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.

 AYJ

Received on Monday, 18 July 2011 02:22:00 UTC