RFC 2068

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 servers 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 proxys capabilities and which are known to be
   unavailable through that proxy.