The request has succeeded. The information returned with the
   response is dependent on the method used in the request, as follows:

   GET    an entity corresponding to the requested resource is sent
          in the response;

   HEAD   the response must only contain the header information and
          no Entity-Body;

   POST   an entity describing or containing the result of the action.

   201 Created

   The request has been fulfilled and resulted in a new resource being
   created. The newly created resource can be referenced by the URI(s)
   returned in the entity of the response. The origin server should
   create the resource before using this Status-Code. If the action
   cannot be carried out immediately, the server must include in the
   response body a description of when the resource will be available;
   otherwise, the server should respond with 202 (accepted).

   Of the methods defined by this specification, only POST can create a
   resource.

   202 Accepted

   The request has been accepted for processing, but the processing
   has not been completed. The request may or may not eventually be
   acted upon, as it may be disallowed when processing actually takes
   place. There is no facility for re-sending a status code from an
   asynchronous operation such as this.

   The 202 response is intentionally non-committal. Its purpose is to
   allow a server to accept a request for some other process (perhaps
   a batch-oriented process that is only run once per day) without
   requiring that the user agent's connection to the server persist
   until the process is completed. The entity returned with this
   response should include an indication of the request's current
   status and either a pointer to a status monitor or some estimate of
   when the user can expect the request to be fulfilled.

   204 No Content

   The server has fulfilled the request but there is no new
   information to send back. If the client is a user agent, it should
   not change its document view from that which caused the request to




 
RFC 1945                        HTTP/1.0                        May 1996


   be generated. This response is primarily intended to allow input
   for scripts or other actions to take place without causing a change
   to the user agent's active document view. The response may include
   new metainformation in the form of entity headers, which should
   apply to the document currently in the user agent's active view.

9.3  Redirection 3xx

   This class of status code indicates that further action needs to be
   taken by the user agent in order to fulfill the request. The action
   required may be carried out by the user agent without interaction
   with the user if and only if the method used in the subsequent
   request is GET or HEAD. A user agent should never automatically
   redirect a request more than 5 times, since such redirections usually
   indicate an infinite loop.

   300 Multiple Choices

   This response code is not directly used by HTTP/1.0 applications,
   but serves as the default for interpreting the 3xx class of
   responses.

   The requested resource is available at one or more locations.
   Unless it was a HEAD request, the response should include an entity
   containing a list of resource characteristics and locations from
   which the user or user agent can choose the one most appropriate.
   If the server has a preferred choice, it should include the URL in
   a Location field; user agents may use this field value for
   automatic redirection.

   301 Moved Permanently

   The requested resource has been assigned a new permanent URL and
   any future references to this resource should be done using that
   URL. Clients with link editing capabilities should automatically
   relink references to the Request-URI to the new reference returned
   by the server, where possible.

   The new 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 URL.

   If the 301 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.