Re: #160: Redirects and non-GET methods

+1

On 01/09/2011, at 12:30 AM, Julian Reschke wrote:

> 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.
> 

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

Received on Wednesday, 31 August 2011 22:02:55 UTC