Proposed fix for issued 140

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

Received on Saturday, 18 July 2009 14:04:49 UTC