Re: #160: Redirects and non-GET methods

On 2011-08-31 10:17, Julian Reschke wrote:
> On 2011-08-31 08:15, Mark Nottingham wrote:
>>
>> On 31/08/2011, at 4:12 PM, Julian Reschke wrote:
>>
>>> "The action required MAY be carried out by the user agent without
>>> interaction with the user if and only if the method used in the
>>> second request is known to be "safe", as defined in Section 6.1.1." ...
>>
>> Right. The problem is that when you combine that requirement with the
>> proposed text, it doesn't make a lot of sense, because there is no
>> "second request' for a 304 response...
>
> Indeed, but that's a problem with the old text as well.
>
> Let's do a minimal fix, so that we can treat issue #238 as separate
> problem...:
>
> "If the required action involves a subsequent HTTP request, it MAY be
> carried out by the user agent without interaction with the user if and
> only if the method used in the second request is known to be "safe", as
> defined in Section 6.1.1."
>
> Best regards, Julian

I did some more work, adding a note explaining the history of 
301/302/303/307 (removing the text from the individual descriptions), 
and add text allowing the rewrite of POST->GET for 301/302 (this is what 
issue 160 is about).

With this Section 7.3 would become:

7.3.  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.  If the
    required action involves a subsequent HTTP request, it MAY be carried
    out by the user agent without interaction with the user if and only
    if the method used in the second request is known to be "safe", as
    defined in Section 6.1.1.

    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
        agent-driven content negotiation (Section 5.2 of [Part3]).  This
        is status code 300 (Multiple Choices).

    4.  Other kinds of redirection, such as to a cached result (status
        code 304 (Not Modified)).

       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 due
       to backwards compatibility reasons, 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 make that behavior compliant in case the original
       request was POST.

    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.

7.3.1.  300 Multiple Choices

    The target resource has more than one representation, each with its
    own specific location, and agent-driven negotiation information
    (Section 5 of [Part3]) is being provided so that the user (or user
    agent) can select a preferred representation by redirecting its
    request to that location.

    Unless it was a HEAD request, the response SHOULD include a
    representation containing a list of representation metadata and
    location(s) from which the user or user agent can choose the one most
    appropriate.  The data format is specified by the media type given in
    the Content-Type header field.  Depending upon the format and the
    capabilities of the user agent, selection of the most appropriate
    choice MAY be performed automatically.  However, this specification
    does not define any standard for such automatic selection.

    If the server has a preferred choice of representation, it SHOULD
    include the specific URI for that representation in the Location
    field; user agents MAY use the Location field value for automatic
    redirection.

    Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
    determine freshness for 300 responses.

7.3.2.  301 Moved Permanently

    The target resource has been assigned a new permanent URI and any
    future references to this resource SHOULD use one of the returned
    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 returned by the server, where possible.

    Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
    determine freshness for 301 responses.

    The new permanent URI SHOULD be given by the Location field in the
    response.  Unless the request method was HEAD, the representation of
    the response SHOULD contain a short hypertext note with a hyperlink
    to the new URI(s).

    If the 301 status code is received in response to a request method
    that is known to be "safe", as defined in Section 6.1.1, then the
    request MAY be automatically redirected by the user agent without
    confirmation.  Otherwise, the user agent MUST NOT automatically
    redirect the request unless it can be confirmed by the user, since
    this might change the conditions under which the request was issued.

       Note: For historic reasons, user agents MAY change the request
       method from POST to GET for the subsequent request.  If this
       behavior is undesired, status code 307 (Temporary Redirect) can be
       used instead.

7.3.3.  302 Found

    The target resource resides temporarily under a different URI.  Since
    the redirection might be altered on occasion, the client SHOULD
    continue to use the effective request URI for future requests.

    The temporary URI SHOULD be given by the Location field in the
    response.  Unless the request method was HEAD, the representation of
    the response SHOULD contain a short hypertext note with a hyperlink
    to the new URI(s).

    If the 302 status code is received in response to a request method
    that is known to be "safe", as defined in Section 6.1.1, then the
    request MAY be automatically redirected by the user agent without
    confirmation.  Otherwise, the user agent MUST NOT automatically
    redirect the request unless it can be confirmed by the user, since
    this might change the conditions under which the request was issued.

       Note: For historic reasons, user agents MAY change the request
       method from POST to GET for the subsequent request.  If this
       behavior is undesired, status code 307 (Temporary Redirect) can be
       used instead. [[issue312: but see
       <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/312>]]


   (....remainder unchanged)

See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>; feedback 
appreciated.

Best regards, Julian

PS: and yes, there are more open issues regarding redirects; this change 
is for issue 160 only.

Received on Wednesday, 31 August 2011 14:31:38 UTC