RFC 2068                        HTTP/1.1                    January 1997


19.6 Additional Features

   This appendix documents protocol elements used by some existing HTTP
   implementations, but not consistently and correctly across most
   HTTP/1.1 applications. Implementers should be aware of these
   features, but cannot rely upon their presence in, or interoperability
   with, other HTTP/1.1 applications. Some of these describe proposed
   experimental features, and some describe features that experimental
   deployment found lacking that are now addressed in the base HTTP/1.1
   specification.

19.6.1 Additional Request Methods

19.6.1.1 PATCH

   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



Fielding, et. al.           Standards Track                   [Page 156]

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.