8

RFC规定：

10.4.6 405 方法不允许

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

但是，我无法识别出符合该 MUST 的单个服务器。

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

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

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

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

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

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

4

1 回答 1

2

试图直接回答问题：

  1. 该要求仍然有意义，尤其是 - 正如Meryn 对 HATEOAS API 的评论所说。

  2. 由于服务器是“一个接受连接以通过发回响应来为请求提供服务的应用程序”，因此很容易说是 - 网络上有依赖于它的应用程序。;) 一个这样的用例是响应with405以指示资源不是“工厂资源”。POST /resource/1/Allow: GET, HEAD, PUT, DELETE

  3. 由于资源上允许的方法可能因应用程序逻辑而异，因此我们还应该考虑应用程序服务器 - 正如您在问题中指出的那样。在这种情况下，是的 - 例如，django 返回一个Allow带有405响应的正确标头。

于 2014-11-09T12:15:35.487 回答