RE: 301/302
Arthur Bierer (arthurbi@microsoft.com)
Wed, 30 Jul 1997 11:17:34 -0700
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