Table of contents
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.
Responses to this method are not cacheable.
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 indicated by a Content-Type field. Although this
specification does not define any use for such a body, future
extensions to HTTP might use the OPTIONS body to make more detailed
queries on the server. A server that does not support such an extension
MAY discard the request body.
If the Request-URI is an asterisk ("*"), the OPTIONS request is
intended to apply to the server in general rather than to a specific
resource. Since a server's communication options typically depend on
the resource, the "*" request is only useful as a "ping" or "no-op"
type of method; it does nothing beyond allowing the client to test the
capabilities of the server. For example, this can be used to test a
proxy for HTTP/1.1 compliance (or lack thereof).
If the Request-URI is not an asterisk, the OPTIONS request
applies only to the options that are available when communicating with
A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".
Max-Forwards request-header field MAY be used to target a specific
proxy in the request chain. When a proxy receives an OPTIONS request on
an absoluteURI for which request forwarding is permitted, the proxy
MUST check for a Max-Forwards field. If the Max-Forwards field-value is
zero ("0"), the proxy MUST NOT forward the message; instead, the proxy
SHOULD respond with its own communication options. If the Max-Forwards
field-value is an integer greater than zero, the proxy MUST decrement
the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.