Making 307 redirects permantent, Re: Issue 160 (Redirects and non-GET methods)

Hi,

part of the things we need to do with respect to solving the 301/302 
method rewriting problem is to make the 307 status more generic, 
allowing permanent redirects as well.

The proposal for this is to use cache-control information. Below is a 
proposed rewrite of the section defining status 307, now simply called 
"307 Redirect". See also 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/160/160.diff>.

-- snip --
8.3.8.  307 Redirect

    The target resource resides under a different URI.

    The permanence of this condition can be expressed using cache control
    header fields such as "Cache-Control" and "Expires".

    For instance, recipients SHOULD treat redirect messages with a "max-
    age" directive specifying 2147483647 (2^31 - 1) seconds (Section 3.2
    of [Part6]) as permanent.

    When no additional information is specified, the condition SHOULD be
    treated as temporary.

    For temporary redirects, the client SHOULD continue to use the
    effective request URI for future requests.

    For permanent redirects, 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.

    The redirect 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), since many pre-HTTP/1.1 user agents do not
    understand the 307 status code.  Therefore, the note SHOULD contain
    the information necessary for a user to repeat the original request
    on the new URI.

    If the 307 status code is received in response to a request method
    that is known to be "safe", as defined in Section 7.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.
-- snip --

Feedback appreciated, Julian

Received on Monday, 11 October 2010 15:37:28 UTC