W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

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

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 24 Oct 2012 23:02:41 +1100
Cc: Maciej Stachowiak <mjs@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DA0C95E1-B54A-4514-802B-15433F12B90D@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC