2013-03-28 38 views
7

The RFC状态:HTTP 405 - Web服务器遵守

10.4.6 405不允许的方法

在Request-Line中指定的方法是不允许通过该项要求确定的 资源URI。响应必须包含一个 允许标题,其中包含请求的 资源的有效方法列表。

但是,我一直无法确定哪一台服务器符合那个必须。

鉴于存在各种代理,动态应用程序等,我可以看到,要求将是非常难与现代Web服务器难以满足。

  1. 为什么历史上这个要求是否有意义?
  2. 什么都取决于那种行为,或者曾经有过吗?它的用例是什么?
  3. 不要任何网络服务器“正常”实现HTTP这方面?据我所知,IIS(至少在使用ASP.NET时)甚至一些“RESTful”API在给出伪造方法时返回404而不是405。

此外,为什么服务器为BOGUS等服务返回405,即使在服务文档时,即使在代理出或调用某些代码(cgi/etc)时,它们也应该返回501 ?

如果HTTP的这些部分被认为是“退化”,看到几乎没有任何服务器符合规范?


实际上,对于大多数框架来说,正确地返回“允许”并不困难。我所知道的所有框架都需要指定特定控制器将被调用哪些方法(通常默认为GET),代码可以轻松地将扩展方法注册到框架以便返回。

到目前为止的证据似乎指向无论是)没有人读的规范,没有人知道这个要求,二)没有人关心这个功能。

+1

根据我的经验,除非服务器背后的代码(不管是CGI,servlet,whatnot)被破坏,否则它将不会检查方法名称。 –

+0

我测试了www.microsoft.com的IIS/ASP.NET和api.github.com(以及其他一些),返回404而不是405. 我更关心的'允许'标题应该返回,虽然,比实际状态(虽然我发现服务器返回405时,他们应该返回501,我会更新与该问题...) –

+1

“我一直无法确定一个单服务器必须符合那个“ - 也不是Apache或Nginx,当提供静态文件?我认为由自定义代码驱动的服务器不实现规范中较不重要的部分并不奇怪。对于大多数开发人员来说,开发RESTful API大多局限于“动词正确”(即HTTP动词)。 HATEOAS API更可能符合。 –

回答

2

尝试直接回答的问题:

  1. 要求仍然是有道理的,尤其是 - 作为Meryn's comment说,对HATEOAS的API。

  2. 由于a server is "An application program that accepts connections in order to service requests by sending back responses"很容易说的是 - 有在网络上依赖于它的应用程序。 )一种这样的使用情况是响应405POST /resource/1/Allow: GET, HEAD, PUT, DELETE以指示资源不是"factory resource"

  3. 由于允许上的资源可以通过应用程序逻辑不同,我们还应该考虑应用服务器的方法 - 当你在你的问题指出。在这种情况下,是的 - 例如,django returns a proper Allow header with 405 responses