9.2 OPTIONS
The OPTIONS method presents a request for information about the communication options available in the request / response chain identified by the Request-URI. This method allows the client to determine the parameters and / or requirements associated with the resource, or server capabilities, without implying a resource action or initiating a resource search.
Responses to this method are not cached.
If the OPTIONS request includes an entity body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be specified in the Content-Type field. Although this specification does not define any use for such a body, future HTTP extensions may use the OPTIONS body to create more detailed requests on the server. A server that does not support such an extension MAY refuse the request body.
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to be applied to the server as a whole, and not to a specific resource. Since the parameters of communication with the server are usually resource-dependent, the request "*" is only useful as the "ping" or "no-op" method; it does nothing, except that the client can check the capabilities of the server. For example, this can be used to check proxies for HTTP / 1.1 compliance (or lack thereof).
If the Request-URI is not an asterisk, the OPTIONS request applies only to the parameters available when communicating with this resource.
The answer for 200 SHOULD include any header fields that indicate additional functions implemented by the server and applicable to this resource (for example, Allow), possibly including extensions not defined by this specification. The response authority, if any, MUST also include information on communication options. The format for such an authority is not defined by this specification, but may be defined by future HTTP extensions. Content negotiation MAY be used to select the appropriate response format. If the response body is not included, the response MUST contain a Content-Length field with a value field of "0".
The Max Forward request header field MAY be used to target a specific proxy server in the request chain. When a proxy receives an OPTIONS request on an absolute URI that is allowed to forward the request, the proxy MUST check the Max-Forwards field. If the value of the Max-Forwards field is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy MUST respond with its own communication parameters. If the value of the Max-Forwards field is an integer greater than zero, the proxy MUST decrease the value of the field when it forwards the request. If the request does not have a Max-Forwards field, then the forwarded request MUST NOT include the Max-Forwards field.
9.4 HEAD
The HEAD method is identical to GET, except that the server SHOULD NOT return the message body in response. The metadata contained in the HTTP headers in response to the HEAD request MUST be identical to the information sent in response to the GET request. This method can be used to obtain meta-information about the entity implied by the request, without transferring the object-object itself. This method is often used to check for hypertext links for authenticity, accessibility, and recent modification.
The response to the HEAD request MAY be cached in the sense that the information contained in the response MAY be used to update a previously cached object from this resource. If the new field values indicate that the cached object is different from the current object (as indicated in the change in Content-Length, Content-MD5, ETag, or Last-Modified), then the cache MUST consider the cache entry obsolete.