Method Not Allowed

Description

Examples

PUT /api/system/status HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer token123

{"status": "maintenance"}

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Content-Length: 127 
{"error": "method_not_allowed", "message": "PUT is not supported for /api/system/status. Supported methods: GET, HEAD, OPTIONS."}

DELETE /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer admin-token

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST, HEAD
Content-Type: application/json

{"error": "method_not_allowed", "message": "Cannot DELETE the entire /users collection. DELETE individual users at /api/users/{id}."}

Edge Cases

• •The Allow header is REQUIRED in a 405 response — omitting it violates the spec and leaves clients guessing which methods work.
• •405 is about the RESOURCE, not the server. The same server can return 405 on /read-only and accept PUT on /writable.
• •CORS preflight uses OPTIONS. If OPTIONS returns 405, the browser treats it as a CORS failure. Always handle OPTIONS on endpoints that need cross-origin access.
• •Some frameworks return 404 when a resource exists but doesn't support the method. This is incorrect — 405 with Allow is the right response.
• •HEAD should almost never return 405 — RFC 9110 requires that any resource supporting GET must also support HEAD.
• •The Allow header values should match the actual route definitions. If you add a new method to an endpoint, update the Allow list.

When You'll See This

• →Sending PUT or DELETE to a read-only resource (like a public API status page)
• →POST to an endpoint that only accepts GET (e.g., a search endpoint that uses query params)
• →Attempting to PATCH a resource that only supports full replacement via PUT
• →Trying to DELETE an entire collection when only individual items are deletable
• →CORS preflight failure because OPTIONS isn't handled (appears as 405 to the server, CORS error to the browser)

Implementation References

History

Introduced in HTTP/1.1 (RFC 2068, 1997). Became essential with RESTful API design where each resource explicitly declares which HTTP methods it supports. Before REST, most web servers only used GET and POST, making 405 rare. Modern API frameworks auto-generate 405 responses from route definitions — Express, FastAPI, Spring, and Rails all handle this differently.

Related Status Codes

Related Headers

FAQ