Re: 301/302

>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.

Personally, I don't care what decision is made, provided that BEFORE
any change is made to the document that we receive EXPLICIT WRITTEN
CONFIRMATION FROM EVERY SINGLE MAJOR WWW SOFTWARE ORGANIZATION that
the given solution is either

   a) How their existing software is implemented.

   b) How their next version of the software *will* be implemented.

I can tell you right now that Apache 1.2 is implemented according to
RFC 2068, but also that it would be no great hardship for us to swap
the meaning of 302 and 303 in the next version.  We won't be happy about
it, but it's not the first time we have had to change our implementation
just because some browser developers can't read or are somehow unable to
participate in an open WG.

   2) If 303 has no definition and is not currently being used, then
      why not use it for temporary redirects?

The answer depends on whether there exist any deployed implementations
of 303 that would be adversely affected by the change.  I know of none
other than the W3C libwww, and I don't know if it would be a problem.
Henrik is probably the only one who can answer that.

>My guess is that nobody was present who wants to implement or use the
>"true redirection" functionality (what 302 currently says, proposed for
>307).  Maybe there is nobody using it, and there will never be an
>implementation.  In that case it would be more honest to just completely
>get rid of it, instead of just pushing it around, first to 302, then to
>303.  Specifying something for 303 which won't get used, and in addition
>is completely contrary to RFC 2068, doesn't reduce cruft.

Rephrasing, that would be

   3) If there is no known reason to temporarily redirect a non-GET
      request, then why do we need a status code for it?

The answer to that depends on whether there will ever be a new method
that needs a temporary redirect, and it is impossible to know that.
Two+ years ago we anticipated the needs of future applications and
developed a solution to satisfy those needs.  It just wasn't implemented
by Netspryglassoft.

....Roy

Received on Friday, 29 August 1997 06:33:43 UTC