Subject: Re: Issue 160 (Redirects and non-GET methods)

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 01 Oct 2010 13:24:02 +0200

On Wed, 29 Sep 2010 13:51:04 +0200, Julian Reschke <[email-masked]>  
wrote:
> On 29.09.2010 13:28, Anne van Kesteren wrote:
>> Agreed, but it is way more ugly than what the other browsers do in my
>> opinion and might cause people to avoid using POST (in favor of CHICKEN)
>> just because of this rather than simply start using 307 which will work
>> everywhere.
>
> I'm not concerned so much about new stuff; yes, we should recommend 307  
> if you want method preservation.
>
> I *am* concerned about cases where 301 and 302 *today* are used as  
> described in RFC 2616 (non-browser scenarios).

Those would break today if they use POST in IE and would break everywhere  
else completely. Those would work today if they switched to 307.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Oct 2010 13:32:15 +0200

On 01.10.2010 13:24, Anne van Kesteren wrote:
> On Wed, 29 Sep 2010 13:51:04 +0200, Julian Reschke
> <[email-masked]> wrote:
>> I'm not concerned so much about new stuff; yes, we should recommend
>> 307 if you want method preservation.
>>
> Those would break today if they use POST in IE and would break
> everywhere else completely. Those would work today if they switched to 307.

No, those do not break at all. Browsers aren't the only HTTP clients we 
need to consider.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Oct 2010 17:36:52 +0200

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