How to respond to an HTTP OPTIONS request?

The HTTP OPTIONS method is supposedly used to determine what other methods the server supports on a given resource. Given that, I have two questions:

• What does this response look like? I have seen examples with CSV lists in Public, Allow, and even Access-Control-Allow-Methods headers. Are they all needed? What's the difference? RFC 2616 doesn't seem to be very helpful here.

• Would it be appropriate to use this to list the actions that a resource supports in a non-REST-API environment? For example, if my ConversionController supports the action convert, would a response like this make sense:

Request:

OPTIONS /conversion HTTP/1.1

Response:

HTTP/1.1 200 OK
...
Allow: CONVERT
...

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)

• https://stackoverflow.com/questions/15381105/cors-what-is-the-motivation-behind-introducing-preflight-requests

• How to exploit HTTP Methods

In response to the title: "How to respond to an HTTP OPTIONS request?" To answer that, I'd want to know why you want to respond to an OPTIONS request? Who/what is sending you an OPTIONS request, and why? Many public servers respond with some form of "error" or "not allowed" (500, 501, 405). So, unless you're in a specific situation where your clients will be reasonably sending OPTIONS requests and expecting useful/meaningful information back (e.g., WebDAV, CORS), you probably want to respond with: "don't do that."

In terms of your question about the "OPTIONS /conversion HTTP/1.1" request: unless you know that there's some client of your server, a client which would send an OPTIONS request to "/conversion" and expect a response with "Allow: CONVERT," the answer is no: it wouldn't make sense to respond like that. I think that most implementations that do support OPTIONS and respond with "Allow," respond with standard HTTP methods.

Here's a great article on the topic.

Summary: OPTIONS is immediately problematic because it doesn't support caching. Alternatives: server-wide metadata: try well-known URI's. Resource-specific: try using a Link header on its responses, or a link in the representation format for that resource.

Lastly, if what you're after is a service description, have a look at WADL or RSDL.

EDIT:

dotnetguy makes a good point in the comment below: OPTIONS is undeniably valuable in certain contexts (e.g., CORS); I certainly didn't mean to suggest otherwise.