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
Allowedheader 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 Allowedor501 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
PUTorDELETE, orPOSTwithapplication/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
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.