300 Status Code (Redirection)

The requested resource corresponds to any one of a set of representations, each with its own
specific location, and agent- driven negotiation information (section 12) is being provided so that the
user (or user agent) can select a preferred representation and redirect its request to that location.

The entity format is specified by the media type given in the Content-type header field. Depending
upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY
be performed automatically. However, this specification does not define any standard for such
automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that
representation in the Location field; user agents MAY use the Location field value for automatic
redirection. This response is cacheable unless indicated otherwise.

301 (Moved Permanently)

The requested resource has been assigned a new permanent URI and any future references to this
resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to
automatically relink references to the Request-URI to one or more of the new references returned by
the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent 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 301 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.

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.

303 (See Other)

The response to the request can be found under a different URI and SHOULD be retrieved using a
GET method on that resource. This method exists primarily to allow the output of a POST-activated
script to redirect the user agent to a selected resource. The new URI is not a substitute reference for
the originally requested resource. The 303 response MUST NOT be cached, but the response to the
second (redirected) request might be cacheable.

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

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