FW: Protocols

Two codes seem to represent a temporary redirect:
 
 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

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.
 

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)
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.

I don't see why 302 is called found. In all the work that I have done
on sites I have never seen a site redirect using a 307 but many that
are using 302. Can you say that you see the error code 307 used on
sites? It just seems that 302 has become synonymous with a temporary
redirect. If so why is there a 307? Could (should) the 302 be amended
to say Found - Temporary Redirect?


Thanks,
Andrew Nevelos

Received on Sunday, 16 April 2006 00:10:46 UTC