Re: 301/302

"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> wrote:
>>Klaus Weide <kweide@tezcat.com> wrote:
>>If the people present in Munich came to a different consensus, I would
>>very much like to know why.  The Issues Page currently has "Consensus at
>>IETF seems to be to swap the codes, rather than making the protocol
>>cruftier."  Can someone explain why it is better to make 303 as currently
>>specified unusable, rather than just adjusting the specification as
>>much as necessary (as dictated by reality)?
>
>I wasn't at Munich, but I can guess at the reasons.
>
>   1) If 302 (as implemented) really means See Other, then why confuse
>      users by also having 303 have that definition?
>
>Foteos asked a while back for a little historical perspective.  I've been
>too busy lately, but I'll describe the *real* history of 302 now because
>I am tired of people accusing us of making an arbitrary decision.
>
>The 1993 specification lists both 302 and 303, with the 302 code being
>described as a "redirection that may be altered on occasion" and 303
>described as a method changing redirect in which a "Method" header field
>was used to give the UA the new method to use, and the response body
>contained the parameters that the UA should send in its redirected
>request body.
>
>For obvious security reasons, that definition of 303 was never implemented
>and the code was later deprecated.  There was no clear statement for 302
>regarding whether or not the redirected request should always be a GET
>(as in See Other) or a repeat of the original request.  When Henrik and I
>started rewriting the HTTP/1.0 specification in October 1994, all of the
>code we had access to redirected with the same method, so that is how we
>defined it.
>
>The issue did not arise in the WG until 23 March 1995,
>
>   http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q1/0189.html
>
>and was later repeated on 18 June 1995, when Bill Perry asked about it
>
>   http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q2/0196.html
>
>and Henrik gave a convincing reason why he implemented it as described
>in the specification, and why we should use 303 for "See Other". 
>Consensus was that different people implemented it differently, and
>therefore a decision was made that the most natural definition would be
>given as 302 and a new status code 303 would be used for "See Other".
>
>The discussion arose again on 1 September 1995 when Chris Lilley posed an
>alternative solution in
>
>   http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q3/0548.html
>
>and the only response was mine (regarding we already solved it with 303).
>The next time it was discussed was 30 Jan 1996
>
>   http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q1/0173.html
>
>Please note that at no time during this period did any of the Browser
>developers say that they were not going to implement 303, or that they
>preferred some solution other than 303.  We have an interoperability
>problem now because, apparently, none of the major browser vendors read
>specifications in 1995.
>[...]

	See the appended, additional message from that set, also highly
germane to your review.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

	<URL:http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q1/0199.html>
	Thu, 23 Mar 95 17:47:59 -0600
   
  Jeffrey Perry writes:
  >What appears to happen when a POST is redirected is the client attempts a
  >GET at the new URL so that the user can fill-in the form again (it may have
  >changed when it moved)

  There are several pages on the Web ("The Revolving Door" comes to mind)
  which, on the basis of form input, redirect you to one of a number of
  different pages.  These pages then need to be retrieved using GET.  This
  usage appears to be much more common than a redirect where the client is
  supposed to POST again on the target system.

  At a very early stage of development, Enhanced Mosaic would actually do
  another POST after a redirect.  In every case that this happened, it
  generated incorrect results (like an "Action not allowed" response).  I
  think that switching to GET after a redirect is current practice for most
  browsers.

  --
  Jim Seidman, Senior Software Engineer, Spyglass Inc.

Received on Friday, 29 August 1997 07:39:44 UTC