87

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
...
FtDRbwLXw6
  • 25,206
  • 12
  • 61
  • 102

3 Answers3

20

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/).

kjhughes
  • 89,675
  • 16
  • 141
  • 199
Julian Reschke
  • 35,455
  • 7
  • 78
  • 83
  • Thank you for the clarification. In the case of CORS, should both the `Allow` and `Access-Control-Allow-Methods` be sent, or just the latter? – FtDRbwLXw6 Aug 13 '12 at 15:07
  • I would always return "Allow", thus not special-case CORS. – Julian Reschke Aug 13 '12 at 16:50
  • 7
    What about content? Can body content be available? – CMCDragonkai Jan 31 '14 at 11:50
  • 2
    @CMCDragonkai Yes, `OPTIONS` may have content. From RFC 2616: "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." – bishop Sep 26 '16 at 17:20
  • I believe that both `Allow` and `Access-Control-Allow-Methods` are required if you want to use CORS. The former specifies which methods are supported in general and latter specifies which methods are allowed for cross-origin requests. For example, you might allow `GET`, `POST`, `PUT` and `DELETE` for your own origin but only allow `GET` and `POST` for cross-origin. – Mikko Rantalainen Sep 28 '17 at 07:50
9

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.

Hawkeye Parker
  • 5,502
  • 5
  • 38
  • 43
  • 4
    The article is good, and by and authority, but see the section "Why is HTTPbis leaving OPTIONS in, then" and comments. With CORS, a REST system should be able to respond to OPTIONS especially if the APIs are going to be used from a JavaScript based web application. It is common for JS frameworks to fire a "preflight" options request before the actual HTTP call. – Sudhanshu Mishra Apr 22 '15 at 05:42
  • I saw OPTIONS requests when I connect my (self written) http server from macOS Finder ([using Webdav](http://www.webdav.org)). – Joe Sep 26 '17 at 09:56
9

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

Suragch
  • 364,799
  • 232
  • 1,155
  • 1,198