10.4.7 406 Not Acceptable

   The resource identified by the request is only capable of generating
   response entities which have content characteristics not acceptable
   according to the accept headers sent in the request.

   Unless it was a HEAD request, the response SHOULD include an entity
   containing a list of available entity characteristics and location(s)
   from which the user or user agent can choose the one most
   appropriate.  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.

     Note: HTTP/1.1 servers are allowed to return responses which are
     not acceptable according to the accept headers sent in the request.
     In some cases, this may even be preferable to sending a 406
     response. User agents are encouraged to inspect the headers of an
     incoming response to determine if it is acceptable. If the response
     could be unacceptable, a user agent SHOULD temporarily stop receipt
     of more data and query the user for a decision on further actions.

10.4.8 407 Proxy Authentication Required

   This code is similar to 401 (Unauthorized), but indicates that the
   client MUST first authenticate itself with the proxy. The proxy MUST
   return a Proxy-Authenticate header field (section 14.33) containing a
   challenge applicable to the proxy for the requested resource. The
   client MAY repeat the request with a suitable Proxy-Authorization
   header field (section 14.34). HTTP access authentication is explained
   in section 11.






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


10.4.9 408 Request Timeout

   The client did not produce a request within the time that the server
   was prepared to wait. The client MAY repeat the request without
   modifications at any later time.

10.4.10 409 Conflict

   The request could not be completed due to a conflict with the current
   state of the resource. This code is only allowed in situations where
   it is expected that the user might be able to resolve the conflict
   and resubmit the request. The response body SHOULD include enough
   information for the user to recognize the source of the conflict.
   Ideally, the response entity would include enough information for the
   user or user agent to fix the problem; however, that may not be
   possible and is not required.

   Conflicts are most likely to occur in response to a PUT request. If
   versioning is being used and the entity being PUT includes changes to
   a resource which conflict with those made by an earlier (third-party)
   request, the server MAY use the 409 response to indicate that it
   can't complete the request. In this case, the response entity SHOULD
   contain a list of the differences between the two versions in a
   format defined by the response Content-Type.

10.4.11 410 Gone

   The requested resource is no longer available at the server and no
   forwarding address is known. This condition SHOULD be considered
   permanent. Clients with link editing capabilities SHOULD delete
   references to the Request-URI after user approval. If the server does
   not know, or has no facility to determine, whether or not the
   condition is permanent, the status code 404 (Not Found) SHOULD be
   used instead.  This response is cachable unless indicated otherwise.

   The 410 response is primarily intended to assist the task of web
   maintenance by notifying the recipient that the resource is
   intentionally unavailable and that the server owners desire that
   remote links to that resource be removed. Such an event is common for
   limited-time, promotional services and for resources belonging to
   individuals no longer working at the server's site. It is not
   necessary to mark all permanently unavailable resources as "gone" or
   to keep the mark for any length of time -- that is left to the
   discretion of the server owner.







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


10.4.12 411 Length Required

   The server refuses to accept the request without a defined Content-
   Length. The client MAY repeat the request if it adds a valid
   Content-Length header field containing the length of the message-body
   in the request message.

10.4.13 412 Precondition Failed

   The precondition given in one or more of the request-header fields
   evaluated to false when it was tested on the server. This response
   code allows the client to place preconditions on the current resource
   metainformation (header field data) and thus prevent the requested
   method from being applied to a resource other than the one intended.