Clarification on HTTP redirects 301,302, and 307

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.

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.

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.

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

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

On 2014-01-16, at 8:15 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

> Thanks. I believe http://tools.ietf.org/search/draft-ietf-httpbis-p2-semantics-25 does cover the issue. 
> 
> Though
> 
> Phil
> 
>> On Jan 16, 2014, at 8:03, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 
>>> On 2014-01-16 17:00, Phil Hunt wrote:
>>> Thanks.  2616 should be changed.
>> 
>> The point being that the definitions of the redirect codes have been rewritten a lot in HTTPbis.
>> 
>> Optimally, there is no need to have an additional document *at all*.
>> 
>>> ...
>> 
>> Best regards, Julian
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

Received on Thursday, 16 January 2014 19:10:15 UTC