Subject: Proposed fix for issued 140

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Jul 2009 16:04:01 +0200

Hi,

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/140>:

"Part2 notes about status 302:

"Note: [RFC1945] and [RFC2068] specify that the client is not allowed to 
change the method on the redirected request. However, most existing user 
agent implementations treat 302 as if it were a 303 response, performing 
a GET on the Location field-value regardless of the original request 
method. The status codes 303 and 307 have been added for servers that 
wish to make unambiguously clear which kind of reaction is expected of 
the client."

This needs to be rephrased in terms of RFC2616 instead of RFC2068 (I 
think)."

On closer investigation, citing RFC 1945 and 2068 is correct here; thus 
my proposal is to just rephrase the Note so it becomes clearer *why* 
we're citing those, and also explain that 303 and 307 have been 
introduced on RFC2616.

The note would then say:

       Note: HTTP/1.0 ([RFC1945], Section 9.3) and the first version of
       HTTP/1.1 ([RFC2068], Section 10.3.3) specify that the client is
       not allowed to change the method on the redirected request.
       However, most existing user agent implementations treat 302 as if
       it were a 303 response, performing a GET on the Location field-
       value regardless of the original request method.  Therefore, a
       previous version of this specification ([RFC2616], Section 10.3.3)
       has added the status codes 303 and 307 for servers that wish to
       make unambiguously clear which kind of reaction is expected of the
       client.

I also noticed that 303/307 were not mentioned in the "Changes from 
RFC2068" section, and thus added in A.1:

    303 (See Also) and 307 (Temporary Redirect) added to address user
    agent failure to implement status code 302 properly.  (Section 8.3.4,
    and 8.3.8)

Full proposal patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/140/i140.diff>

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 20 Jul 2009 01:47:29 +0200

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/140/i140.diff>

+1

Regards
Henrik

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 20 Jul 2009 11:19:10 +1000

Browsers (eg Firefox 3.5 & IE8) seem to change the method (eg POST to GET) on 301 "Moved Permanently" redirects as well as on 302 "Found" redirects even with HTTP/1.1 requests & responses, contradicting the spec.

The spec sections on 301 & 302 each have a note about the mismatches -- but the notes are different. The 302 note says "most existing user agents" change the method, while the 301 note says "some existing HTTP/1.0 user agents" change the method. The 301 note does not seem to reflect reality.

I am NOT suggesting a new status code (308 "Permanently Redirect") for unambiguous semantics -- using 307 "Temporary Redirect" with Cache-Control should be close enough.

Perhaps the new text for the 302 note should also be used for the 301 note [issue #140 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/140].

James Manger
[email-masked]
Identity and security team — Chief Technology Office — Telstra

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jul 2009 08:56:32 +0200

> The spec sections on 301 & 302 each have a note about the mismatches -- but the notes are different. The 302 note says "most existing user agents" change the method, while the 301 note says "some e…

We are already tracking this in 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>.

> I am NOT suggesting a new status code (308 "Permanently Redirect") for unambiguous semantics -- using 307 "Temporary Redirect" with Cache-Control should be close enough.

It seems to be different to me. To give it the desired semantics we 
probably would have to change the spec, in which case a new status code 
seems more plausible to me.

> Perhaps the new text for the 302 note should also be used for the 301 note [issue #140 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/140].

We can't use the same text, as there is no replacement status for 301. 
That being said, we should make sure that the Note reflect reality.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Jul 2009 13:32:17 +0200

>> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/140/i140.diff>

Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/614>.

(Note that the other issue related to 301/302, 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>, remains open).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Jul 2009 15:02:04 +0200

Manger, James H wrote:
> ...

For the record: the user agents I just tested which rewrite POST to GET 
will also do the same for PUT and DELETE (see Mark's test cases at 
<http://www.mnot.net/javascript/xmlhttprequest/>).

BR, Julian