Re: #388: User interface requirements for redirecting to unsafe methods

+1

On 24/10/2012, at 10:24 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2012-10-24 03:39, Mark Nottingham wrote:
>> Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/388>. Is editorial, since the decision was already made in #238.
>> ...
> 
> I believe we can just drop that sentence, as there's another paragraph later on that deals with the issue. With that change, the introduction would read:
> 
> 7.4.  Redirection 3xx
> 
>   This class of status code indicates that further action needs to be
>   taken by the user agent in order to fulfill the request.
> 
>   There are several types of redirects:
> 
>   1.  Redirects of the request to another URI, either temporarily or
>       permanently.  The new URI is specified in the Location header
>       field.  In this specification, the status codes 301 (Moved
>       Permanently), 302 (Found), and 307 (Temporary Redirect) fall
>       under this category.
> 
>   2.  Redirection to a new location that represents an indirect
>       response to the request, such as the result of a POST operation
>       to be retrieved with a subsequent GET request.  This is status
>       code 303 (See Other).
> 
>   3.  Redirection offering a choice of matching resources for use by
>       reactive content negotiation (Section 3.4.2).  This is status
>       code 300 (Multiple Choices).
> 
>   4.  Other kinds of redirection, such as to a cached result (status
>       code 304 (Not Modified), see Section 4.1 of [Part4]).
> 
>      Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
>      and 302 (Found) were defined for the first type of redirect, and
>      the second type did not exist at all ([RFC1945], Section 9.3).
>      However it turned out that web forms using POST expected redirects
>      to change the operation for the subsequent request to retrieval
>      (GET).  To address this use case, HTTP/1.1 introduced the second
>      type of redirect with the status code 303 (See Other) ([RFC2068],
>      Section 10.3.4).  As user agents did not change their behavior to
>      maintain backwards compatibility, the first revision of HTTP/1.1
>      added yet another status code, 307 (Temporary Redirect), for which
>      the backwards compatibility problems did not apply ([RFC2616],
>      Section 10.3.8).  Over 10 years later, most user agents still do
>      method rewriting for status codes 301 and 302, therefore this
>      specification makes that behavior conformant in case the original
>      request was POST.
> 
>   A Location header field on a 3xx response indicates that a client MAY
>   automatically redirect to the URI provided; see Section 8.1.2.
> 
>   Note that for methods not known to be "safe", as defined in
>   Section 5.2.1, automatic redirection needs to done with care, since
>   the redirect might change the conditions under which the request was
>   issued.
> 
>   Clients SHOULD detect and intervene in cyclical redirections (i.e.,
>   "infinite" redirection loops).
> 
>      Note: An earlier version of this specification recommended a
>      maximum of five redirections ([RFC2068], Section 10.3).  Content
>      developers need to be aware that some clients might implement such
>      a fixed limitation.
> 
> (see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/388/388.diff>)
> 
> Best regards, Julian
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 24 October 2012 12:02:48 UTC