HTTP 405 Method Not Allowed — What It Means & How to Debug

HTTP 405 Method Not Allowed is an HTTP response status code that indicates the server received and recognized the request target but refuses to process it because the HTTP method used by the client is not supported for that endpoint. When a 405 is returned, the server MUST include an Allow header listing the methods that are permitted for the resource.

What It Means

The HTTP specification defines the 405 status code in RFC 7231 Section 6.5.5. It belongs to the 4xx class of client error responses. The key distinction between 405 and other 4xx codes is that the server knows the resource exists and understands the request — the problem is specifically that the method in the request line (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, etc.) is not in the set of methods the server permits for that URI.

The Allow response header is critical here. Its value is a comma-separated list of HTTP methods. For example:

Allow: GET, HEAD, OPTIONS

Clients and intermediary proxies can use this header to automatically retry the request with an allowed method or to present appropriate options to the user.

When It’s Sent

A server sends a 405 response in several common scenarios:

• REST API misuse — A client sends a POST to an endpoint that only accepts GET requests.
• Read-only resources — A client attempts PUT or DELETE on a resource mounted as read-only.
• Misconfigured routes — A web framework route is defined without the intended method constraint.
• Static file servers — Most static file servers only allow GET and HEAD; POST or DELETE requests return 405.
• API version mismatch — An older client sends a method that a newer API version no longer supports.

Real Example

The following curl command sends a POST request to a resource that only allows GET and HEAD:

curl -v -X POST https://jsonplaceholder.typicode.com/posts/1

Expected response (truncated):

* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 405
< allow: GET, HEAD, OPTIONS
< content-type: application/json; charset=utf-8
< ...
{
  "message": "Method Not Allowed"
}

The allow header in the response tells you exactly which methods are valid for future requests.

How to Debug

Client-Side

1. Check the Allow header — Inspect the response headers. The Allow field lists the valid methods. Retry with one of those.
2. Confirm the endpoint URL — Ensure you are hitting the correct path. A 404 means the resource doesn’t exist; a 405 means it exists but the method is wrong.
3. Review client HTTP library configuration — Some HTTP clients default to POST or GET. Verify which method your code is actually sending (e.g., requests.post() vs requests.get() in Python).
4. Examine request payload — Tools like curl -v, browser dev tools, or Wireshark capture show the exact HTTP method in the request line.

Server-Side

1. Inspect route definitions — Check your framework’s route table (e.g., Express app.get() vs app.post(), Django @require_http_methods).
2. Check middleware — Authentication, CORS, or rate-limiting middleware may intercept and reject methods before they reach the route handler.
3. Review reverse proxy rules — Nginx, Apache, or cloud load balancers like AWS ALB may block methods at the proxy layer.
4. Look for Allow header configuration — Ensure your server framework automatically populates the Allow header or that you are setting it manually.

Common Causes Table

FAQ

Related Codes

HTTP 403 Forbidden — The server understood the request but refuses to authorize it.

HTTP 404 Not Found — The server cannot find the requested resource.

HTTP 406 Not Acceptable — The server cannot produce a response matching the Accept headers.

HTTP 501 Not Implemented — The server does not support the functionality needed to fulfill the request.