The PATCH method is similar to PUT except that the entity contains a
   list of differences between the original version of the resource
   identified by the Request-URI and the desired content of the resource
   after the PATCH action has been applied. The list of differences is
   in a format defined by the media type of the entity (e.g.,
   "application/diff") and MUST include sufficient information to allow
   the server to recreate the changes necessary to convert the original
   version of the resource to the desired version.

   If the request passes through a cache and the Request-URI identifies
   a currently cached entity, that entity MUST be removed from the
   cache.  Responses to this method are not cachable.

   The actual method for determining how the patched resource is placed,
   and what happens to its predecessor, is defined entirely by the
   origin server. If the original version of the resource being patched
   included a Content-Version header field, the request entity MUST
   include a Derived-From header field corresponding to the value of the
   original Content-Version header field. Applications are encouraged to
   use these fields for constructing versioning relationships and
   resolving version conflicts.

   PATCH requests must obey the message transmission requirements set
   out in section 8.2.

   Caches that implement PATCH should invalidate cached responses as
   defined in section 13.10 for PUT.

19.6.1.2 LINK

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




 
RFC 2068                        HTTP/1.1                    January 1997


   allowing links to be established between resources is that the LINK
   method does not allow any message-body to be sent in the request and
   does not directly result in the creation of new resources.

   If the request passes through a cache and the Request-URI identifies
   a currently cached entity, that entity MUST be removed from the
   cache.  Responses to this method are not cachable.

   Caches that implement LINK should invalidate cached responses as
   defined in section 13.10 for PUT.

19.6.1.3 UNLINK

   The UNLINK method removes one or more Link relationships from the
   existing resource identified by the Request-URI. These relationships
   may have been established using the LINK method or by any other
   method supporting the Link header. The removal of a link to a
   resource does not imply that the resource ceases to exist or becomes
   inaccessible for future references.

   If the request passes through a cache and the Request-URI identifies
   a currently cached entity, that entity MUST be removed from the
   cache.  Responses to this method are not cachable.

   Caches that implement UNLINK should invalidate cached responses as
   defined in section 13.10 for PUT.

19.6.2 Additional Header Field Definitions

19.6.2.1 Alternates

   The Alternates response-header field has been proposed as a means for
   the origin server to inform the client about other available
   representations of the requested resource, along with their
   distinguishing attributes, and thus providing a more reliable means
   for a user agent to perform subsequent selection of another
   representation which better fits the desires of its user (described
   as agent-driven negotiation in section 12).














 
RFC 2068                        HTTP/1.1                    January 1997


   The Alternates header field is orthogonal to the Vary header field in
   that both may coexist in a message without affecting the