如何响应 HTTP 选项请求？

HTTPOPTIONS方法可能用于确定服务器在给定资源上支持哪些其他方法。鉴于此，我有两个问题:

  • 这种反应看起来像什么？我在 Public、 Allow甚至 Access-Control-Allow-Methods头文件中看到过 CSV 列表的例子。都需要吗？有什么区别吗？RFC 2616在这里似乎没有什么帮助。

  • 使用它来列出资源在非 REST-API 环境中支持的操作是否合适？例如，如果我的 ConversionController支持动作 convert，这样的响应是否有意义:

要求:

OPTIONS /conversion HTTP/1.1

回应:

HTTP/1.1 200 OK
...
Allow: CONVERT
...
77194 次浏览
小开
最佳答案

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

小开

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.

小开

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


提交答案