D.1  Additional Request Methods

D.1.1 PUT

   The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI. If the Request-URI refers to an already
   existing resource, the enclosed entity should be considered as a
   modified version of the one residing on the origin server. If the
   Request-URI does not point to an existing resource, and that URI is
   capable of being defined as a new resource by the requesting user
   agent, the origin server can create the resource with that URI.

   The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity as data to be processed. That resource may be a data-accepting
   process, a gateway to some other protocol, or a separate entity that
   accepts annotations. In contrast, the URI in a PUT request identifies
   the entity enclosed with the request -- the user agent knows what URI
   is intended and the server should not apply the request to some other
   resource.

D.1.2 DELETE

   The DELETE method requests that the origin server delete the resource
   identified by the Request-URI.

D.1.3 LINK

   The LINK method establishes one or more Link relationships between
   the existing resource identified by the Request-URI and other
   existing resources.

D.1.4 UNLINK

   The UNLINK method removes one or more Link relationships from the
   existing resource identified by the Request-URI.

D.2  Additional Header Field Definitions

D.2.1 Accept

   The Accept request-header field can be used to indicate a list of
   media ranges which are acceptable as a response to the request. The
   asterisk "*" character is used to group media types into ranges, with
   "*/*" indicating all media types and "type/*" indicating all subtypes




 
RFC 1945                        HTTP/1.0                        May 1996


   of that type. The set of ranges given by the client should represent
   what types are acceptable given the context of the request.

D.2.2 Accept-Charset

   The Accept-Charset request-header field can be used to indicate a
   list of preferred character sets other than the default US-ASCII and
   ISO-8859-1. This field allows clients capable of understanding more
   comprehensive or special-purpose character sets to signal that
   capability to a server which is capable of representing documents in
   those character sets.

D.2.3 Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-coding values which are acceptable in the
   response.

D.2.4 Accept-Language

   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request.

D.2.5 Content-Language

   The Content-Language entity-header field describes the natural
   language(s) of the intended audience for the enclosed entity. Note
   that this may not be equivalent to all the languages used within the
   entity.

D.2.6 Link

   The Link entity-header field provides a means for describing a
   relationship between the entity and some other resource. An entity
   may include multiple Link values. Links at the metainformation level
   typically indicate relationships like hierarchical structure and
   navigation paths.

D.2.7 MIME-Version

   HTTP messages may include a single MIME-Version general-header field
   to indicate what version of the MIME protocol was used to construct
   the message. Use of the MIME-Version header field, as defined by RFC
   1521 [5], should indicate that the message is MIME-conformant.
   Unfortunately, some older HTTP/1.0 servers send it indiscriminately,