W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: 301/302

From: Klaus Weide <kweide@tezcat.com>
Date: Fri, 5 Sep 1997 16:19:07 -0500 (CDT)
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970905154602.1298M-100000@xochi.tezcat.com>
On Fri, 5 Sep 1997, Roy T. Fielding wrote:

> That's pretty good, but I'd suggest a few tweaks ...
> 
> 10.3.3 302 Found             ["Found" was the original 302 reason-phrase]

"Found" never made much sense to me...

>    ...[ text for 302, amended to allow UAs "converting" to GET ]...
> 
>    Note: RFC 1945 and RFC 2068 specify that the client should not
>    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.

My formulation made it more explicit that the meaning of 302 had
changed, and tried to give some more motivation for the change.  Maybe
my text was too verbose, but I would prefer to see some of that
retained.  Now it reads a bit as if addition of 303 and 307 were the
only change.

> 10.3.4 303 See Other
>    ....[ text for 303, as now ]...
> 
>    Note: Many pre-HTTP/1.1 user agents do not understand the 303 status.
>    When interoperatibility with such clients is a concern, the 302 status
>    code may be used instead, since most user agents react to a
>    302 response as described here for 303.
> 
> 10.3.8 307 Temporary Redirect
>    ....[ basically copy old 302 text here, without current "Note" ]...
> 
>    Note: Many pre-HTTP/1.1 user agents do not understand the 307 status.
>    An appropriate response entity should contain the information necessary
>    for a user to repeat the original request on the new URL.

Hmm, for a truly-redirected POST request, that could mean that the
response entity should contain a HTML FORM with METHOD=POST ?
But true non-GET redirection isn't currently being used AFAIK, and we
don't know how it will be used (if it is used); your addition seems
like a good idea.

Overall, I have no big problem with your tweaks.

    Klaus
Received on Friday, 5 September 1997 14:24:11 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:00 EDT