405 - Method Not Allowed
HTTP 405 Method Not Allowed means the resource exists but does not support the HTTP method used.
Last reviewed: February 20, 2026|Editorial standard: source-backed technical guidance
What Does Method Not Allowed Mean?
The target resource is reachable, but this operation is blocked because the selected HTTP method is not one of the methods that resource currently allows.
Common Causes
- -Endpoint method map allows GET only, but frontend prefetch sends HEAD and framework does not auto-handle it.
- -CORS preflight OPTIONS reaches upstream where OPTIONS handler is disabled by gateway or WAF policy.
- -HTTP to HTTPS redirect chain rewrites original POST into GET, and origin rejects method for that resource.
How to Fix Method Not Allowed
- 1Read the
Allowresponse header and switch to one of the supported methods for that resource. - 2Align client method selection with endpoint contracts and method-specific routing rules.
- 3Retest with a minimal request using an allowed method and persist this case in contract tests.
Step-by-Step Diagnosis for Method Not Allowed
- 1Capture full request metadata and confirm which method reached the origin.
- 2Inspect the
Allowheader and compare it to the documented contract for that URI. - 3Trace gateway, WAF, and method-override middleware for unexpected method rewrites.
- 4Retest with one of the advertised methods and verify behavior is consistent across environments.
Method Contract and Allow Header Audit
- -Verify the server returns
Allowwith the currently supported method set (example:Allow: GET, HEAD, POSTwhile client sendsPATCH). - -Check whether endpoint documentation and runtime router tables diverge (example: docs mention
DELETE, router disabled it after policy change).
Routing and Middleware Method Trace
- -Audit method-override behavior across proxies and frameworks (example:
_method=PUTconverted toPOSTby intermediary middleware). - -Inspect CORS/preflight and edge rules that can block intended verbs before origin evaluation (example:
OPTIONSunsupported at API gateway stage).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 405 Method Not Allowed
# {"error":"Method Not Allowed","code":"405"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 405) {
console.error('Handle 405 Method Not Allowed');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 405:
print('Handle 405 Method Not Allowed')How to Verify the Fix
- -Re-run the request and confirm 405 is cleared when using an allowed method.
- -Verify every 405 response includes an accurate
Allowheader for that resource. - -Confirm SDKs and generated clients now emit only contract-supported methods.
How to Prevent Recurrence
- -Publish strict endpoint contracts for methods and accepted representations.
- -Add contract tests for unsupported methods, media types, and negotiation headers.
- -Version and validate gateway rules together with origin API specifications.
Pro Tip
- -build a CI check that diffs declared OpenAPI methods against live router introspection so undocumented method drift is caught pre-release.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.