HTTP 405 - Web服务器合规性

Question

RFC规定:

10.4.6 405不允许的方法

请求行中指定的方法不允许由Request-URI标识的资源.响应必须包含一个Allow标头,其中包含所请求资源的有效方法列表.

但是,我一直无法确定一台符合MUST的服务器.

我可以看到,这一要求将是非常考虑到存在的各种代理,动态应用程序等,很难与现代的Web服务器来完成.

1. 从历史上看,为什么这个要求有意义？
2. 有什么依赖于这种行为,还是曾经做过？它的用例是什么？
3. 不要任何网络服务器"正常"实现HTTP这方面？IIS(至少在使用ASP.NET时)甚至一些"RESTful"API在给出伪造方法时返回404而不是405,据我所知.

另外,为什么服务器返回405用于BOGUS等明显未由服务器实现的方法,即使在提供文档而不代理或调用某些代码(cgi/etc)时,它们应该返回501？

如果HTTP的这些部分被认为是"残留的",那么如果有任何服务器符合规范,那么这些部分是否很少？

---

实际上,大多数框架都没有那么难以正确地返回'允许'.我所知道的所有框架都需要指定将要调用特定控制器的方法(通常默认为GET),并且代码可以轻松地向框架注册扩展方法以便返回.

到目前为止,证据似乎指向a)没有人阅读规范,没有人知道这个要求,b)没有人关心这个功能.

Answer 1

尝试直接回答问题：

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

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

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