HTTP 405——网络服务器合规性答案

【问题标题】：HTTP 405 -- web server complianceHTTP 405——网络服务器合规性
【发布时间】：2013-03-19 01:31:44
【问题描述】：

The RFC 状态：

10.4.6 405 方法不允许

Request-Line 中指定的方法不允许用于由 Request-URI 标识的资源。响应必须包含一个允许包含请求的有效方法列表的标头资源。

但是，我无法确定符合该 MUST 的单个服务器。

我可以看到，考虑到存在的代理、动态应用程序等的多样性，现代 Web 服务器很难满足该要求。

为什么从历史上看，这个要求有意义？
有什么依赖于这种行为，还是曾经有过？它的用例是什么？
任何 Web 服务器是否“正确”实现了 http 的这一方面？据我所知，IIS（至少在使用 ASP.NET 时）甚至某些“RESTful”API 在提供虚假方法时返回 404 而不是 405。

此外，为什么服务器会返回 405，例如 BOGUS 等显然不是由服务器实现的方法，即使在提供文档而不代理或调用某些代码（cgi/etc）时，它们应该返回 501？

是否应该将 HTTP 的这些部分视为“残留的”，如果有服务器符合规范的话，那么就很少吗？

实际上，大多数框架正确返回“允许”并不难。我所知道的所有框架都需要指定将调用特定控制器的方法（通常默认为 GET），并且代码可以轻松地向框架注册扩展方法以使其返回。

到目前为止，证据似乎表明：a）没有人阅读规范，也没有人知道这个要求，b）没有人关心这个功能。

【问题讨论】：

根据我的经验，您确实会得到 405，除非服务器背后的代码（无论是 CGI、servlet 等等）因为它不检查方法名称而被破坏。跨度>
我为 IIS/ASP.NET 测试了 www.microsoft.com，以及返回 404 而不是 405 的 api.github.com（以及其他一些）。我更关心的是但是，应该返回的“允许”标头比实际状态（尽管我发现服务器在应该返回 501 时返回 405，我将用那个更新问题...）
“我无法识别符合该 MUST 的单个服务器” - 也不是 Apache 或 Nginx，在提供静态文件时？我认为由自定义代码驱动的服务器没有实现规范中不太重要的部分并不奇怪。对于大多数开发人员来说，开发 RESTful API 主要限于“正确使用动词”（即 HTTP 动词）。 HATEOAS API 更有可能符合要求。
在一个人们以 200 OK 返回“错误（未授权/未知资源/任何）”消息的世界中，这个问题展示了一种只属于浪漫主义者的纯洁心灵。 ;-)
另外，“BOGUS”是一个有效的令牌，可以用作 HTTP 请求方法，所以服务器返回 405 是正确的：这是不允许的。服务器不一定知道是否有任何资源确实支持动词。可能有应用程序在服务器上运行，因此 501 不涵盖：“这是当服务器无法识别请求方法时的适当响应并且无法支持任何资源".

【解决方案1】：

尝试直接回答问题：

仍然的要求是有道理的，尤其是 - 正如 Meryn's comment 对 HATEOAS API 所说的那样。
因为a server is "An application program that accepts connections in order to service requests by sending back responses" 很容易说是 - 网络上有依赖它的应用程序。 ;) 一个这样的用例是用 Allow: GET, HEAD, PUT, DELETE 响应 405 到 POST /resource/1/ 以指示资源不是 "factory resource"。
由于资源允许的方法可能因应用程序逻辑而异，我们还应该考虑应用程序服务器 - 正如您在问题中指出的那样。在这种情况下，是的 - 例如，django returns a proper Allow header with 405 responses。

【讨论】：