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

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

Received on Wednesday, 24 October 2012 11:31:42 UTC