* * * * *

                             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 [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.