RE: 301/302

Agreed.
	Yaron

> -----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 Thursday, 31 July 1997 14:30:17 UTC