问如何响应HTTP OPTIONS请求？

EN

RFC2616定义了“允许”(http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7)。"Public“不再使用。“访问-控制-允许-方法”在CORS规范中定义(参见http://www.w3.org/TR/cors/)。

什么是HTTP OPTIONS请求？

这是一个来自客户端的请求，要求知道服务器将允许哪些HTTP方法，如GET、POST等。

请求

当询问特定资源的选项时，请求可能如下所示：

OPTIONS /index.html HTTP/1.1

或者像这样询问一般的服务器：

OPTIONS * HTTP/1.1

响应

响应将包含一个Allow标头，其中包含允许的方法：

Allow: OPTIONS, GET, HEAD, POST

为什么服务器收到HTTP OPTIONS请求？

API API某些REST API需要它(但如果您正在定义

• ，您应该知道将其作为“预装”请求发送到服务器，以查看服务器是否理解并发送它以获取有关

的更多信息

如何响应HTTP OPTIONS请求？

• 您可以使用Allowed标头进行响应，甚至可以在正文中使用document your API进行响应。
• 您可以使用CORS定义的其他Access-Control-Request-*标头进行响应。
• 您可以使用405 Method Not Allowed或code进行响应

如何停止获取HTTP OPTIONS请求？

如果它来自浏览器，那么更新你的

• ，这样它就不会做任何“危险的”事情(比如PUT或DELETE，或者使用application/json的POST )。仅执行simple requests.

另请参阅

• 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

回应标题：“如何响应HTTP选项请求？”要回答这个问题，我想知道您为什么要响应OPTIONS请求？谁/什么在向您发送OPTIONS请求，为什么？Many public servers respond with some form of "error" or "not allowed" (500501405)。因此，除非您处于特定情况下，即您的客户端将合理地发送OPTIONS请求并期望返回有用/有意义的信息(例如，WebDAV、CORS)，否则您可能希望这样回应：“不要这样做。”

对于您提出的关于"OPTIONS /conversion HTTP/1.1“请求的问题:除非您知道服务器上有某个客户端，该客户端将向"/conversion”发送OPTIONS请求，并期望得到带有"Allow: CONVERT“的响应，否则答案是否定的:这样响应是没有意义的。我认为大多数支持选项并以"Allow“响应的实现都使用标准的HTTP方法进行响应。

Here's a great article on the topic。

摘要: OPTIONS马上就会出问题，因为它不支持缓存。替代方案:服务器范围的元数据:尝试well-known URI's。特定于资源:尝试在其响应上使用Link header，或者在该资源的表示格式中使用链接。

最后，如果您想要的是服务描述，可以看看WADL或RSDL。

编辑：

dotnetguy在下面的评论中提出了一个很好的观点:在某些情况下(例如CORS)，选项无疑是有价值的；我当然不是有意要提出相反的建议。