How to respond to an HTTP OPTIONS request?

RFC 2616 defines "Allow" (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7). "Public" is not in use anymore. "Access-Control-Allow-Methods" is defined in the CORS specification (see http://www.w3.org/TR/cors/).

What is an HTTP OPTIONS request?

It is a request from the client to know what HTTP methods the server will allow, like GET, POST, etc.

Request

The request might look like this when asking about the options for a particular resource:

OPTIONS /index.html HTTP/1.1

or like this when asking about the server in general:

OPTIONS * HTTP/1.1

Response

The response would contain an Allow header with the allowed methods:

Allow: OPTIONS, GET, HEAD, POST

Why is the server receiving an HTTP OPTIONS request?

• Some REST APIs need it (but if you are defining the API, you'd know that)
• Browsers send it to servers as "preflighted" requests to see if the server understands CORS
• Attackers send it to get more information about the API

How to respond to an HTTP OPTIONS request?

• You could respond with an Allowed header and even document your API in the body.
• You could respond with additional CORS defined Access-Control-Request-* headers.
• You could respond with 405 Method Not Allowed or 501 Not Implemented.

How do I stop getting HTTP OPTIONS requests?

• If it's coming from a browser then update your API so that it isn't doing anything "dangerous" (like PUT or DELETE, or POST with application/json). Only perform simple requests.

See also

• RFC 2616 Section 9: Method definitions
• MDN Web docs: OPTIONS
• MDN Web docs: Cross-Origin Resource Sharing (CORS)
• CORS - What is the motivation behind introducing preflight requests?
• How to exploit HTTP Methods