10.3.2 301 Moved Permanently

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

   If the new URI is a location, its URL 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.

     Note: When automatically redirecting a POST request after receiving
     a 301 status code, some existing HTTP/1.0 user agents will
     erroneously change it into a GET request.







Fielding, et. al.           Standards Track                    [Page 57]

RFC 2068                        HTTP/1.1                    January 1997


10.3.3 302 Moved Temporarily

   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 cachable if indicated by a Cache-Control or Expires header
   field.

   If the new URI is a location, its URL 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: When automatically redirecting a POST request after receiving
     a 302 status code, some existing HTTP/1.0 user agents will
     erroneously change it into a GET request.

10.3.4 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 is not cachable, but the response to the second (redirected)
   request MAY be cachable.

   If the new URI is a location, its URL 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).

10.3.5 304 Not Modified

   If the client has performed a conditional GET request and access is
   allowed, but the document has not been modified, the server SHOULD
   respond with this status code. The response MUST NOT contain a
   message-body.








Fielding, et. al.           Standards Track                    [Page 58]

RFC 2068                        HTTP/1.1                    January 1997


   The response MUST include the following header fields:

  o  Date

  o  ETag and/or Content-Location, if the header would have been sent in
     a 200 response to the same request

  o  Expires, Cache-Control, and/or Vary, if the field-value might
     differ from that sent in any previous response for the same variant

   If the conditional GET used a strong cache validator (see section
   13.3.3), the response SHOULD NOT include other entity-headers.
   Otherwise (i.e., the conditional GET used a weak validator), the
   response MUST NOT include other entity-headers; this prevents
   inconsistencies between cached entity-bodies and updated headers.

   If a 304 response indicates an entity not currently cached, then the
   cache MUST disregard the response and repeat the request without the
   conditional.

   If a cache uses a received 304 response to update a cache entry, the
   cache MUST update the entry to reflect any new field values given in
   the response.

   The 304 response MUST NOT include a message-body, and thus is always
   terminated by the first empty line after the header fields.