405 Method Not Allowed
The URL exists but does not support the HTTP method that was used.
Status
HTTP/1.1 405 Method Not Allowed
Details
- Category: 4xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.5.6
- Cacheable: Cacheable by default
- Response body: Allowed
- Retry: Retry only after changing the request
405 confirms the resource is there and rejects the verb. A collection endpoint that accepts GET and POST answers 405 to a DELETE. The response must include an Allow header listing the methods that are supported, which is the difference between a helpful 405 and a frustrating one.
It also shows up when infrastructure rather than the application refuses the method: static file servers reject POST to a file, and some CDNs and WAFs block PUT, PATCH, or DELETE at the edge before the origin ever sees them.
Headers
- Allow: Required. Comma-separated list of supported methods, e.g. GET, HEAD, POST.
Common causes
- Using POST where the route only defines GET, or the reverse.
- A trailing slash difference routing the request to a different handler.
- A static file server or CDN rejecting write methods.
- A CORS preflight OPTIONS request hitting a route that does not handle OPTIONS.
How to fix it
As the client
- Read the Allow header and use one of the listed methods.
- Check for method override conventions. Some frameworks expect POST with a _method field rather than a real PUT or DELETE.
As the server
- Always send Allow. It costs nothing and removes a support round trip.
- Handle OPTIONS on every route that browsers call cross-origin.
- Return 404 rather than 405 if the existence of the URL should not be revealed.
Examples
DELETE /api/v2/order HTTP/1.1
Host: api.example.com
HTTP/1.1 405 Method Not Allowed
Allow: GET, POST
Content-Type: application/json; charset=utf-8
{"error":"method_not_allowed","allowed":["GET","POST"]}