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 10:35:23 UTC