An HTTP 405 Method Not Allowed response indicates that the server knows the request target resource, but the HTTP method used in the request line is not supported for that target URI.

HTTP 405 at a glance

  • Status: 405
  • Phrase: Method Not Allowed
  • Class: 4xx Client Error
  • Specification: RFC 9110 Section 15.5.6
  • Mandatory header: Allow (must list valid methods for the target)
  • Typical context: Sending POST to a read-only endpoint or unsupported REST action
  • Client retry: Unsafe with the same method; switch to an allowed method

What a 405 response tells you

When a client receives a 405 status code, specific protocol facts are established:

  1. The target resource exists and is recognized: Unlike a 404 Not Found error, the server recognized the request URI and found an active routing definition for it.
  2. The specific HTTP method is rejected: The server refuses to execute the specific method (e.g., POST, PUT, DELETE) on this particular resource.
  3. The server must advertise valid methods: According to RFC 9110 Section 15.5.6, the origin server MUST generate an Allow header field in a 405 response containing a list of the target resource’s currently supported methods.

What a 405 does not tell you

While an HTTP 405 confirms that the method is disallowed, it does not imply other types of failures:

Client -> Web Server / Gateway -> Application Router (Target matched, Method rejected)

Receiving an HTTP 405 does not mean:

  • The URL is wrong or nonexistent (that would be 404 Not Found).
  • The user lacks authentication or authorization (that would be 401 Unauthorized or 403 Forbidden).
  • The request body has syntax errors (that would be 400 Bad Request).
  • The server does not support the HTTP verb at all across any endpoint (that would be 501 Not Implemented).

Similar status codes

Several HTTP status codes handle routing, resource discovery, and method handling. Understanding their differences prevents debugging errors:

404 Not Found

The server cannot find a current representation for the target resource URL. In contrast, 405 proves the resource URL exists, but rejects the HTTP verb.

400 Bad Request

The request cannot be processed due to malformed syntax, invalid framing, or unparseable query parameters.

403 Forbidden

The server understands the request and the method is valid for the endpoint, but refuses authorization for the specific client identity or scope.

501 Not Implemented

The server does not support the HTTP method anywhere across the entire server software (e.g., an esoteric or unrecognized custom HTTP verb). In contrast, 405 indicates the server recognizes the method globally, but disallows it for this specific target URI.

For related status code diagnostics, see our guides on HTTP 400 Bad Request and HTTP 404 Not Found.

Diagnostic scenarios

Two common scenarios illustrate how HTTP 405 errors arise in API integrations:

Scenario 1: Submitting form data via POST to a GET-only route

A client application attempts to submit user preferences or search queries via POST /api/v1/search. However, the API was designed to accept query parameters strictly via GET /api/v1/search?q=term. The server router matches the /api/v1/search route but detects no POST handler, returning 405 with Allow: GET, HEAD, OPTIONS.

Scenario 2: Attempting DELETE on immutable records

A client attempts to delete an entry in a regulatory audit log via DELETE /v1/audit-logs/9821. Because audit logs are append-only by design, the application explicitly omits the DELETE method for the resource controller and returns 405.

Common causes of HTTP 405

Endpoint handler missing for requested HTTP verb

The application routing table defines handlers for some HTTP methods on the path (e.g., GET) but has not registered a handler for the method sent by the client (e.g., POST or DELETE).

Read-only endpoint receiving mutating HTTP requests

The client attempted a state-changing method such as POST, PUT, or PATCH on an endpoint architected strictly for read-only inspection or telemetry.

Reverse proxy or API gateway method filtering

An intermediary web server, load balancer, or CDN policy explicitly blocks or restricts specific HTTP methods (such as PUT or DELETE) before requests reach the application.

Web server default static file handling

A client sent a POST or PUT request directly to a static file path (e.g., /status.html or /data.json) on a web server configured to serve static files only via GET and HEAD.

Headers you may encounter

  • Allow: Mandatory by RFC 9110 Section 15.5.6. Must list all HTTP methods currently supported by the target resource (e.g., Allow: GET, HEAD, POST, OPTIONS).
  • Content-Type: Typically application/problem+json (RFC 7807) detailing why the method was disallowed.
  • Date: The timestamp when the response was generated.

Troubleshooting flow

When troubleshooting an HTTP 405 error, follow this structured diagnostic path:

HTTP 405 Method Not Allowed
  |
  +-- Check the response 'Allow' header.
        |
        +-- Does the list contain the method you sent?
              |
              +-- No: Review API documentation for the correct HTTP verb.
              |
              +-- Yes: Check if an intermediary reverse proxy or CDN
                  is overriding backend response headers.

What to check before changing backend code

Before modifying route definitions or backend controllers, verify client expectations:

  1. Examine the Allow header in the response to determine valid methods.
  2. Check API documentation to confirm whether the endpoint requires GET, POST, PUT, PATCH, or DELETE.
  3. Verify if URL trailing slashes affect routing (e.g., /users vs. /users/).
  4. Inspect reverse proxy configuration (e.g., NGINX limit_except directives).
  5. Check if CORS preflight (OPTIONS) requests are correctly handled by the server stack.

How to verify the fix

Test the endpoint with curl using the --head (-I) flag or an allowed HTTP method to inspect the Allow header:

curl -i -X POST https://api.example.test/v1/status

Inspect the response headers to confirm that the Allow header lists all valid methods (e.g., Allow: GET, HEAD, OPTIONS), then repeat the request using an allowed method:

curl -i https://api.example.test/v1/status

Remediation paths to evaluate

If the client sent the wrong HTTP method

Update the client application or SDK call to use the correct HTTP verb documented by the API contract.

If the backend route is missing a verb handler

Add the corresponding controller method (e.g., @PostMapping in Spring, router.post() in Express, or POST handler in Next.js/Astro) to the route definition.

If a reverse proxy or CDN is blocking methods

Adjust NGINX, Cloudflare, or AWS API Gateway security rules to allow the necessary HTTP verbs through to the origin server.

FAQ

Is the Allow header required in a 405 response?

Yes. RFC 9110 Section 15.5.6 explicitly specifies that the origin server MUST generate an Allow header field in a 405 response containing a comma-separated list of the target resource’s currently supported methods.

What is the difference between 404 and 405?

HTTP 404 Not Found indicates that the server cannot locate the requested URI. HTTP 405 Method Not Allowed confirms that the URI exists and is valid, but rejects the specific HTTP verb used in the request.

What is the difference between 405 and 501?

HTTP 405 indicates that the server recognizes the method globally, but disallows it for that specific URL. HTTP 501 Not Implemented indicates that the server software does not recognize or support the method anywhere on the server.

Key takeaway

HTTP 405 Method Not Allowed confirms that the target resource URL exists but rejects the requested HTTP method. Inspect the mandatory Allow response header to identify which verbs are supported, and ensure both client calls and backend routing tables match the intended API contract.