Clarification requested on use of HTTP Redirect 307

A few days ago I posted draft-hunt-http-rest-redirect, as an attempt to define an issue and suggest a solution. I defined it in turns of the current active draft 2616, though it is to be superseded by the new httpbis drafts.

I wanted to clarify for the the list, the issue as it stands in the current httpbis drafts (that are in final approval).

In the semantics draft, sections 6.42 (301 Moved Permanently) and 6.43 (302 Found), that *both* sections have the same note regarding user agents "MAY" change requests from POST to GET and that if the behaviour is undesired, a 307 (Temporary Redirect) can be used.
> 6.4.2.  301 Moved Permanently
> 
>    The 301 (Moved Permanently) status code indicates that the target
>    resource has been assigned a new permanent URI and any future
>    references to this resource ought to use one of the enclosed URIs.
>    Clients with link editing capabilities ought to automatically re-link
>    references to the effective request URI to one or more of the new
>    references sent by the server, where possible.
> 
>    The server SHOULD generate a Location header field in the response
>    containing a preferred URI reference for the new permanent URI.  The
>    user agent MAY use the Location field value for automatic
>    redirection.  The server's response payload usually contains a short
>    hypertext note with a hyperlink to the new URI(s).
> 
>       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.
> 
>    A 301 response is cacheable by default; i.e., unless otherwise
>    indicated by the method definition or explicit cache controls (see
>    Section 4.2.2 of [Part6]).
> 
> 6.4.3.  302 Found
> 
>    The 302 (Found) status code indicates that the target resource
>    resides temporarily under a different URI.  Since the redirection
>    might be altered on occasion, the client ought to continue to use the
>    effective request URI for future requests.
> 
>    The server SHOULD generate a Location header field in the response
>    containing a URI reference for the different URI.  The user agent MAY
>    use the Location field value for automatic redirection.  The server's
>    response payload usually contains a short hypertext note with a
>    hyperlink to the different URI(s).
> 
> Fielding & Reschke        Expires May 21, 2014                 [Page 56]
> Internet-Draft       HTTP/1.1 Semantics and Content        November 2013
> 
>       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.

I am not sure if it was intentional for servers that want to preserve HTTP requests to use 307 for *both* temporary and permanent redirects. It means clients can't tell if the redirect is permanent or not because they don't know whether the request was originally 301 or 302.

Is it intended that servers can only use 307 temporary redirects if they want to prevent the client from changing the request?

Phil

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