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

Re: 301/302

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Fri, 05 Sep 1997 11:54:21 -0700
To: Klaus Weide <kweide@tezcat.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9709051201.aa01529@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4338
That's pretty good, but I'd suggest a few tweaks ...

10.3.3 302 Found             ["Found" was the original 302 reason-phrase]
   ...[ 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.

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.

Received on Friday, 5 September 1997 12:06:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC