Re: 301/302

On Wed, 3 Sep 1997, Roy T. Fielding wrote:

> It would seem to me, that if 302 really means "see other" in practice,
> then what should be done is change the definition of 302 to "see other",
> define 303 as "same as 302" perhaps including the historical reasons,
> and define 307 as a temporary redirect.  Deprecating a code that is in
> active use is a bad idea.
> 
> BTW, all status codes are HTTP/1.x defined.  A proxy cannot do translation
> of a status code, so basing a response on the received protocol version
> won't work in the presence of proxies.

In response to this, and to Josh's concern (which I summarize as "Just
saying DEPRECATED is confusing or misleading"):

I think we can avoid the word "deprecated", and even the notion.  Some
suggested text for "Note"s:

10.3.3 302 Temporary Redirection
   ...[ text for 302, amended to allow UAs "converting" to GET ]...

   Note: HTTP/1.0 [RFC1945] and a predecessor of this specification
   [RFC2068] required that a client has to use the original request's
   method when following a redirection with 302 status code.  However,
   it was found that most user agent implementations did not follow
   the specifications in this regard and many existing resources expect
   clients to follow a 302 redirection in response to a POST request by
   issuing a GET request.  We now allow both kinds of behavior, and
   provide new status codes 303 and 307 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: This status code was not defined in the HTTP 1.0
   specification [RFC1045] and will not be understood as defined here by
   many existing HTTP 1.0 clients.  When interoperatibility with such
   clients is a concern, the 302 status code can be used instead since
   most user agents react to a 302 response as described here for 303.

10.3.? 307 Repeat Request
   ....[ basically copy existing 302 text here, without current "Note" ]...

   Note: This status code was not defined in the HTTP 1.0
   specification [RFC1045] and will not be understood as defined here by
   existing HTTP 1.0 clients.

(I also changed the reason phrases for 302 and 307, I hope these
correspond better to the meaning.)

Is this better?  No deprecating of existing practice, but rather an
appeal that it may be in the server's (CGI's, ..) best interest 
("servers that wish to make clear...").

For 303, there is nothing that requires checking the request version
(wouldn't work through proxies) or other tricks, but it isn't excluded
either.  Of course "When interoperatibility with such clients is a
concern" currently applies to all deployment on the Internet, but at
some point in the future HTTP/1.0 may have gone (thoretically...).


   Klaus

Received on Thursday, 4 September 1997 13:19:10 UTC