HTTP 405 -- web server compliance

Question

The RFC states:

10.4.6 405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

However, I've been unable to identify a single server which complies with that MUST.

I can see that that requirement would be very hard to fulfill with modern web servers, given the variety of proxying, dynamic applications, etc that exist.

1. Why, historically, did that requirement make sense?
2. Does anything depend on that behavior, or did it ever? What would a use case for it be?
3. Do any web servers "properly" implement this aspect of http? IIS (at least when using ASP.NET) and even some "RESTful" APIs return 404 rather than 405 when giving a bogus method, as far as I've been able to tell.

Additionally, why do servers return 405 for methods such as BOGUS that clearly are not implemented by the server, even when serving documents and not proxying out or calling some code (cgi/etc), when they should return 501?

Should these parts of HTTP be considered "vestigial", seeing as few if any servers conform to the spec?

---

Actually, it isn't that hard for most frameworks to properly return 'Allow'. All of the frameworks I know of require specification of which methods a specific controller is going to be called for (usually defaulting to GET), and code could easily register extension methods with the framework for it to return.

So far the evidence seems to point to either a) nobody reads the spec and nobody knows about this requirement, b) nobody cares about this feature.

Bunny

In my experience, you'll indeed get a 405 unless the code behind the server (be it CGI, a servlet, whatnot) is broken in that it doesn't check the method name. – Medallion

I tested www.microsoft.com for IIS/ASP.NET, and api.github.com (as well as a few others) that returned 404 rather than 405. I'm more concerned about the 'Allow' header that should be returned, though, than the actual status (though I've found that servers return 405 when they should be returning 501, I'll update the question with that one...) – Bunny

"I've been unable to identify a single server which complies with that MUST" - also not Apache or Nginx, when serving static files? I think it's not surprising that servers powered by custom code do not implement the less important parts of the spec. For most developers, developing RESTful API's is mostly limited to "getting the verbs right" (i.e. the HTTP verbs). HATEOAS API's are more likely to conform. – Cutright

I didn't test Apache for static files, but I did test nginx. – Bunny

In a world where people are returning "Error (not authorized/unknown resource/whatever)" messages with 200 OK, this question demonstrates a purity of heart that can only belong to a romantic. ;-) – Phi

I can imagine some DAV-derivative to return 405 for a PUT request on a read-only resource, returning GET as allowed method. – Theosophy

Also, "BOGUS" is a valid token and can be used as an HTTP request method, so the server is correct in returning a 405 on that: it is not allowed. The server does not necessarily know whether any resource does support the verb. There may be applications running on the server that do, so 501 doesn't cover: "This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource". – Theosophy

@CodeCaster: the spec (rfc7231) states "The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource.". So, unless the server knows about "BOGUS", I guess it should return 501 – Racklin

@Racklin did you see the date of my comment and the date on that RFC? I quoted 2616, the authoritative resource at the time. – Theosophy

@CodeCaster: d'oh! you are right :) – Racklin

Answer 1

Trying to directly answer the questions:

1. The requirement still makes sense, especially - as Meryn's comment says for HATEOAS API's.

2. Since a server is "An application program that accepts connections in order to service requests by sending back responses" it's easy to say yes - there are applications on the net that depend on it. ;) One such use case is to respond 405 to a POST /resource/1/ with Allow: GET, HEAD, PUT, DELETE to indicate the resource is not a "factory resource".

3. Since the methods allowed on a resource could vary by application logic, we should also consider application servers - as you point out in your question. In which case, yes - e.g., django returns a proper Allow header with 405 responses.

Dinnage