RFC 1945                        HTTP/1.0                        May 1996


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

   302 Moved Temporarily

   The requested resource resides temporarily under a different URL.
   Since the redirection may be altered on occasion, the client should
   continue to use the Request-URI for future requests.

   The URL must be given by the Location field in the response. Unless
   it was a HEAD request, the Entity-Body of the response should
   contain a short note with a hyperlink to the new URI(s).

   If the 302 status code is received in response to a request using
   the POST method, 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 user agents will
       erroneously change it into a GET request.

   304 Not Modified

   If the client has performed a conditional GET request and access is
   allowed, but the document has not been modified since the date and
   time specified in the If-Modified-Since field, the server must
   respond with this status code and not send an Entity-Body to the
   client. Header fields contained in the response should only include
   information which is relevant to cache managers or which may have
   changed independently of the entity's Last-Modified date. Examples
   of relevant header fields include: Date, Server, and Expires. A
   cache should update its cached entity to reflect any new field
   values given in the 304 response.

9.4  Client Error 4xx

   The 4xx class of status code is intended for cases in which the
   client seems to have erred. If the client has not completed the
   request when a 4xx code is received, it should immediately cease
   sending data to the server. Except when responding to a HEAD request,
   the server should include an entity containing an explanation of the
   error situation, and whether it is a temporary or permanent
   condition. These status codes are applicable to any request method.







 
RFC 1945                        HTTP/1.0                        May 1996


      Note: If the client is sending data, server implementations on TCP
      should be careful to ensure that the client acknowledges receipt
      of the packet(s) containing the response prior to closing the
      input connection. If the client continues sending data to the
      server after the close, the server's controller will send a reset
      packet to the client, which may erase the client's unacknowledged
      input buffers before they can be read and interpreted by the HTTP
      application.

   400 Bad Request

   The request could not be understood by the server due to malformed
   syntax. The client should not repeat the request without
   modifications.

   401 Unauthorized

   The request requires user authentication. The response must include
   a WWW-Authenticate header field (Section 10.16) containing a
   challenge applicable to the requested resource. The client may
   repeat the request with a suitable Authorization header field
   (Section 10.2). If the request already included Authorization
   credentials, then the 401 response indicates that authorization has
   been refused for those credentials. If the 401 response contains
   the same challenge as the prior response, and the user agent has
   already attempted authentication at least once, then the user
   should be presented the entity that was given in the response,
   since that entity may include relevant diagnostic information. HTTP
   access authentication is explained in Section 11.

   403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help and the request should not be repeated.