Re: Clarification on HTTP redirects 301,302, and 307

Both 301 and 302 say to use 307 if conversion to GET is not desired.  

With 307 used for both temporary and perm redirect, 307 loses meaning causing the confusion.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-01-16, at 11:31 AM, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-01-16 20:09, Phil Hunt wrote:
>> Sorry for this, I keep re-reading the httpbis semantics draft, and I must confess, the redirect definitions for 301,302, 307 seem unclear.
>>>       Note: For historic reasons, a user agent MAY change the request
>>>       method from POST to GET for the subsequent request.  If this
>>>       behavior is undesired, the 307 (Temporary Redirect) status code
>>>       can be used instead.
>> 
>> For example, both 301 and 302 essentially allow a client to behave any way it wants.  302, which is essentially a temporary redirect can work either way. Yet, there is 307 which forbids alteration of the HTTP request.
> 
> Not "any way". They can rewrite POST to GET. That's it.
> 
>> From the server perspective, it is confusing as to whether 307 or 302 should be used.  From a client perspective, it is unclear what the client must do when 301 or 302 is used.
> 
> How is it unclear?

> 
>> Even more confusing is that both 301 and 302 say 307 can be used.  Which means now the server cannot indicate whether the redirect is permanent or not.
> 
> Because 308 is a new, experimental status code.
> 
> "Note: This status code is similar to 302 (Found), except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for 301 (Moved Permanently) ([status-308], however, defines the status code 308 (Permanent Redirect) for this purpose)."

> 
>> Why not keep it simple and have 307 and 308 mimic 302 and 301 except with no HTTP request changes being allowed?  The decision tree is much cleaner and the behaviour is cleanly separated.
>> 
>> Apologies if you have already had a long debate on this.
>> 
>> Phil
>> ...
> 
> Best regards, Julian
>

Received on Thursday, 16 January 2014 20:11:53 UTC