RE: 301/302

Klaus,

I thinks this would be the best solution we have so far.  It allows
legacy server scripts and clients to work properly with HTTP 1.1 while
paving the way for 1.1 users to invoke the new and correct behaviors
we've defined.

>From an implementation stand point it would be trivial to add an
additional status code redirect.  But it remains to be seen whether we
can make this change in consensus.

Just my 2-cents (i.e. not those of my company, etc..),
-Arthur Bierer

> -----Original Message-----
> From:	Klaus Weide [SMTP:kweide@tezcat.com]
> Sent:	Wednesday, July 30, 1997 10:34 AM
> To:	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: 301/302 
> 
> On Tue, 29 Jul 1997, Roy T. Fielding wrote:
> 
> > As Foteos hinted, swapping the meaning of 302 and 303 is a solution
> > to the implementation problem.  I don't think it would affect Apache
> much.
> > However, it would require universal agreement among the rest of the
> > implementers, and it would require recycling HTTP/1.1 as Proposed
> > and not as a Draft Standard.  It is not something to be taken
> lightly.
> 
> I hope the idea of just "swapping" 302 and 303 is not being
> entertained
> seriously.  303 is a clean thing and doesn't need to be fixed - don't
> dump the problem on those who have tried to do the right thing.[1]
> 
> If 302 is in such a mess that it effectively cannot be uses for the
> purpose it was always intended to serve, by the protocol designers (in
> connection with non-GET methods) - why, use a new status code for what
> is
> needed (but don't reuse 303!).
> 
> More specific proposal:
> 
>  - Assign a new code (say, 307 - or whichever is the first free
> number).
>    This code means "This resource has moved, and we really mean it.
>    Re-send full messages to the new address (not just empty
> envelopes)."
>    I.e. what 302 was supposed to mean.[2]
> 
>  - Mark 302 as DEPRECATED.  Servers and scripts should use 303 or 307
>    instead, as appropriate.  But for compatibility, not send 307 to
>    older clients.[3].
> 
>  - Describe 302 as a "General Redirection".  For GET requests, the
> meaning
>    is as for 303.  For other methods, the outcome is UNSPECIFIED.
>    - Add some notes explaining this. "Most, but not all, clients will
>    treat a 302 in response to a POST like 303, but don't rely on it."
> 
>  - Clients are required to understand 303 and 307.  Also for
>    compatibility,  they are required to treat 302 in response to a GET
>    like a 303.  If they get 302 in response to another method - well
>    it's up to them how they interpret "General Redirection".[4]
> 
>  - There is no need to change anything about 301 or 303.
> 
> Notes:
> [1] There probably aren't many who use 303.  But at least the lynx
> mailing
>     list has directed people with problems to read the HTTP specs (RFC
> 
>     1945, then the 1.1 draft and later RFC), to read the "Note:"s in
> the
>     301 and 302 descriptions, and to use 303.
> 
> [2] Services needing the "full redirection" behavior of POST, PUT,
> etc.
>    will be new services.  They cannot reliably use 302 for this today
>    anyway, so it's not asking too much to make them use a new status
> code.
>    They are the ones to profit from it.
> 
> [3] Of course that's a problem, if the server cannot reliably detect
> the
>     client's protocol version.  However, this would only affect
> services
>     that really need the 307 behavior - the old "official" 302
> behavior -
>     and they cannot get that reliably today.  So this doesn't make it
>     worse for anyone.  Services requiring the 307 behavior would
> probably 
>     (initially) operate in a controlled environment where out-of-band 
>     information about client version is available (or it can be
> guaranteed
>     that there are no proxies etc.)
> 
> [5] This may seem bad, but I think it's a reflection of how things
> are.
>    This change would give existing implementations a better status
> than they 
>    have with the current wording of RFC 2068 (*and* 1945): Instead of
>    clearly acting "erroneously", they would just be using a deprecated
>    feature.  At the same time this change avoids putting
> implementations
>    in the wrong who have tried to do what RFCs 2068 and 1945 say about
> 302 -
>    therefore this change may be possible without going back to
> "Proposed".
> 
> 
>     Klaus

Received on Wednesday, 30 July 1997 11:16:11 UTC