* * * * *
                                        
                              They're all on crack
                                        
Mark [1] has written an embeded web server he's releasing as open source Real
Soon Now, and a friend of ours, Andrew [2] is writing up the documentation.
He sent a question to Mark, who sent it on to me: 



> [The webserver] has a constant HTTPD_RESP_MOVED_TEMP set to 302. 
> 
> RFC 2616 (Request For Comments---HTTP 1.1) [3] says that 302 means “Found”.
> 307 would be a “temporary redirect”, and 303 would be “see other”. 
> 
> I don't see a clear correspondence here‥ can you explain your reasoning? 
> 

Under an earlier draft (Request for Comments---HTTP 1.1---obsoleted by RFC-
2616) [4] of the HTTP (HyperText Transfer Protocol) 1.1 protocol, a server
response of 302 meant that the object in question is temporarily not
available at the given URI, (Uniform Resource Indicator) but elsewhere. In
the newer draft (Request For Comments---HTTP 1.1) [5] it means something
different, and a response code of 307 means the object in question is
temporarily not available at the given URI, but elsewhere: 



> 
> 10.3.3 302 Found
> 
>    The requested resource resides temporarily under a different URI.
>    Since the redirection might be altered on occasion, the client SHOULD
>    continue to use the Request-URI for future requests.  This response
>    is only cacheable if indicated by a Cache-Control or Expires header
>    field.
> 
>    The temporary URI SHOULD be given by the Location field in the
>    response. Unless the request method was HEAD, the entity of the
>    response SHOULD contain a short hypertext note with a hyperlink to
>    the new URI(s).
> 
>    If the 302 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect the
>    request unless it can be confirmed by the user, since this might
>    change the conditions under which the request was issued.
> 
>       Note: RFC 1945 and RFC 2068 specify that the client is not allowed
>       to change the method on the redirected request.  However, most
>       existing user agent implementations treat 302 as if it were a 303
>       response, performing a GET on the Location field-value regardless
>       of the original request method. The status codes 303 and 307 have
>       been added for servers that wish to make unambiguously clear which
>       kind of reaction is expected of the client.
> 
> 

§10.3.3 of RFC-2616 

> 
> 10.3.8 307 Temporary Redirect
> 
>    The requested resource resides temporarily under a different URI.
>    Since the redirection MAY be altered on occasion, the client SHOULD
>    continue to use the Request-URI for future requests.  This response
>    is only cacheable if indicated by a Cache-Control or Expires header
>    field.
> 
>    The temporary URI SHOULD be given by the Location field in the
>    response. Unless the request method was HEAD, the entity of the
>    response SHOULD contain a short hypertext note with a hyperlink to
>    the new URI(s) , since many pre-HTTP/1.1 user agents do not
>    understand the 307 status. Therefore, the note SHOULD contain the
>    information necessary for a user to repeat the original request on
>    the new URI.
> 
>    If the 307 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect the
>    request unless it can be confirmed by the user, since this might
>    change the conditions under which the request was issued.
> 
> 

§ 10.3.8 of RFC-2616 

Okay, so I couldn't really tell the difference myself (except for the change
of “might” to “MAY” in the first paragraph, and the addtional verbiage in the
second paragraph, and the note added in § 10.3.3, there isn't any difference
(and the additional text doesn't really clarify anything). 

I wrote back: 

> They're all on crack. 
> 
> My response: If you get a “POST <spec> HTTP/1.1” and you need to redirect
> the user to a temporary URI, send back a 307 with enough information to re-
> POST the information at the new URI, otherwise, just send back a 302. 
> 

[1] http://www.conman.org/people/myg/
[2] http://www.korolev.com/amh/
[3] http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2616.html
[4] http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html
[5] http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2616.html

Email author at sean@conman.org

.