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