9 Method Definitions

   The set of common methods for HTTP/1.1 is defined below. Although
   this set can be expanded, additional methods cannot be assumed to
   share the same semantics for separately extended clients and servers.

   The Host request-header field (section 14.23) MUST accompany all
   HTTP/1.1 requests.

9.1 Safe and Idempotent Methods

9.1.1 Safe Methods

   Implementers should be aware that the software represents the user in
   their interactions over the Internet, and should be careful to allow
   the user to be aware of any actions they may take which may have an
   unexpected significance to themselves or others.

   In particular, the convention has been established that the GET and
   HEAD methods should never have the significance of taking an action
   other than retrieval. These methods should be considered "safe." This
   allows user agents to represent other methods, such as POST, PUT and
   DELETE, in a special way, so that the user is made aware of the fact
   that a possibly unsafe action is being requested.

   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in



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


   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them.

9.1.2 Idempotent Methods

   Methods may also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of  N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property.

9.2 OPTIONS

   The OPTIONS method represents a request for information about the
   communication options available on the request/response chain
   identified by the Request-URI. This method allows the client to
   determine the options and/or requirements associated with a resource,
   or the capabilities of a server, without implying a resource action
   or initiating a resource retrieval.

   Unless the server's response is an error, the response MUST NOT
   include entity information other than what can be considered as
   communication options (e.g., Allow is appropriate, but Content-Type
   is not). Responses to this method are not cachable.

   If the Request-URI is an asterisk ("*"), the OPTIONS request is
   intended to apply to the server as a whole. A 200 response SHOULD
   include any header fields which indicate optional features
   implemented by the server (e.g., Public), including any extensions
   not defined by this specification, in addition to any applicable
   general or response-header fields. As described in section 5.1.2, an
   "OPTIONS *" request can be applied through a proxy by specifying the
   destination server in the Request-URI without any path information.

   If the Request-URI is not an asterisk, the OPTIONS request applies
   only to the options that are available when communicating with that
   resource.  A 200 response SHOULD include any header fields which
   indicate optional features implemented by the server and applicable
   to that resource (e.g., Allow), including any extensions not defined
   by this specification, in addition to any applicable general or
   response-header fields. If the OPTIONS request passes through a
   proxy, the proxy MUST edit the response to exclude those options
   which apply to a proxy's capabilities and which are known to be
   unavailable through that proxy.







Fielding, et. al.           Standards Track                    [Page 49]