405 Method Not Allowed

The short version: Run curl -i against the URL and read the Allow header the 405 is required to include. It lists the methods that URL accepts. Then either send one of those, or add the method you need to the route. On IIS, remove the WebDAV module, which claims PUT and DELETE before your app sees them.

Key takeaways

• 405 Method Not Allowed means the resource exists and the server knows the HTTP method, but that method is not permitted on that URL. A POST to a route defined only for GET is the everyday version.
• RFC 9110 requires the response to carry an Allow header listing the methods the resource does accept, so a single curl -i usually tells you the answer outright rather than leaving you to guess.
• This is a routing and configuration error far more often than an application bug. The URL is right, the method is wrong, or the server layer in front of your code refuses the verb before it arrives.
• Two setups produce most of the surprising cases: IIS, where the WebDAV module claims PUT and DELETE before your app sees them, and CORS preflight, where an unhandled OPTIONS request gets a 405 and blocks the real one.
• A 405 is a normal HTTP response, so the server looks healthy from outside. An up-or-down check will call the website up while a form or API endpoint quietly rejects every write.

Error type

HTTP 4xx client error

Whose side

Usually the request; sometimes the server config

Fix difficulty

Easy to moderate

Common cause

The URL does not accept that HTTP method

What does 405 Method Not Allowed mean?

A 405 Method Not Allowed is an HTTP status code in the 4xx family, which places the problem in the request rather than in a server failure. It has a narrow and useful meaning: the resource at that URL exists, the server recognises the method you used, and the method is not permitted on that particular resource. Per RFC 9110 the server must also return an Allow header listing the methods that are permitted, which makes 405 one of the few errors that tells you the fix in the response itself. The distinction from a 404 matters. A 404 says nothing lives at that address. A 405 says something does, you just asked for the wrong operation on it.

In practice this is a routing or configuration error rather than a bug in your application logic. A form posts to a URL that was only ever set up to serve a page. An API route is registered for GET and the client sends POST. A reverse proxy or a server module refuses the verb before it ever reaches your code, which is what happens on IIS, where the WebDAV module claims PUT and DELETE for itself. A browser sends an OPTIONS preflight the route never defined, and the 405 that comes back blocks the real request that would have followed.

405

HTTP status code

4xx

Client-side error class

Allow

Header the response must include

How the 405 Method Not Allowed error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

405

Method Not Allowed

The requested method is not allowed for this resource.

• 405 Method Not Allowed
• HTTP Error 405
• Error 405
• 405 Not Allowed nginx
• HTTP 405.0 Method Not Allowed
• The requested method is not allowed for this resource

405 vs 404, 403 and 501

Each of these refuses the request, but they disagree about what is actually wrong.

Which 4xx code fits which failure

These four all mean the request will not be processed, but they fail for different reasons and are fixed by different people.

What causes 405 Method Not Allowed?

• A form or client sends POST to a URL whose route is defined only for GET. This is the most common cause by a wide margin, and the form's action attribute is usually where it starts.
• An API route registered for the wrong verb, or a client calling PUT where the endpoint expects PATCH, so the path matches but the method does not.
• IIS with the WebDAV module enabled, which intercepts PUT and DELETE before the application sees them and answers 405 on its own.
• A CORS preflight OPTIONS request hitting a route that never defined a handler for OPTIONS, so the router rejects it and the real request is never sent.
• An nginx limit_except block, an Apache <Limit> directive, or a WAF rule that permits only a subset of verbs on a path.
• A redirect that changes the method. Some servers turn a redirected POST into a GET, and a trailing-slash or HTTP-to-HTTPS hop is enough to trigger it.
• Static hosting or a CDN serving a path as a file, where every method except GET and HEAD is refused by design.

How to find the cause fast

1. Send the request with curl -i and read the Allow header on the 405. It names the permitted methods, which frequently ends the investigation on the spot.
2. Confirm which method the client is really sending. Browser devtools shows it on the network row, and a redirect between the request and the final URL can change it without you noticing.
3. Try the same URL with GET. If that works, the resource exists and the problem is genuinely the verb rather than the path.
4. Bypass the proxy or CDN and hit the origin directly. A 405 that disappears at the origin points at an edge rule or a server module rather than your application.

Terminal

curl -i -X POST https://example.com/article/1HTTP/1.1 405 Method Not AllowedAllow: GET, HEAD, OPTIONS# the Allow header names exactly what this URL accepts

How 405 Method Not Allowed looks from the outside

A 405 is a normal HTTP response, so nothing about it looks like an outage from outside: the connection opens, TLS completes, and the reply comes back quickly with the wrong status code. A plain up-or-down ping will report the website up while every form submission and every API write is being refused. It is also asymmetric in a way that hides it, because the GET a monitor usually sends is the one method that still works. To catch this you need a check that exercises the method that matters and asserts the status code it expects, not just one that confirms the host answers.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 405 Method Not Allowed

If you are a visitor

1. Reload the page and submit the form again from a fresh load rather than from a stale tab, in case the page was cached from an older version of the website.
2. Try the action in an incognito window. If an extension is rewriting the request or the URL, that rules it in or out quickly.
3. Check whether you followed a redirect or an old bookmark to reach the form. A saved URL can point at a path that no longer accepts submissions.
4. If the page loads but every submission fails, the fault is on the website's side. There is no visitor-side fix for a route that refuses the method, so report it to the website owner.

If you run the website

1. Read the Allow header your own server returns, then add the missing method to the route or point the client at the URL that already accepts it.
2. Check the form's action attribute. A form posting to the page it lives on, rather than to a handler, produces this error constantly.
3. On IIS, remove the WebDAV handler and the WebDAV module for the site, then confirm the handler mapping lists the verbs your API needs. This is the single most common cause of a REST API returning 405 only in production.
4. On nginx, look for limit_except in the relevant location block. On Apache, check <Limit> directives and .htaccess rules that restrict methods.
5. Handle OPTIONS explicitly on any route that browsers call cross-origin, and return the CORS headers from it, so preflight does not come back 405.
6. Use 307 or 308 rather than 301 or 302 where a redirect must preserve the method, since the older codes allow a client to turn POST into GET.
7. Make sure your 405 responses actually include the Allow header. The specification requires it, and omitting it makes every future report of this error harder to diagnose.

Still not fixed? Next steps

• Run curl -i against the URL and read the Allow header on the 405. It names the methods the resource accepts, which usually turns the whole question into a one-line answer.
• Compare the method your client actually sends with the one the route defines. Frameworks are strict here: a route registered for GET will not answer POST, and a redirect between them can silently change the verb.
• On IIS, remove the WebDAV handler and module for the site. It intercepts PUT and DELETE ahead of your application and is the usual reason an API that works locally returns 405 in production.
• On nginx, look for a limit_except block or a location that only proxies certain methods. On Apache, check <Limit> directives and any .htaccess rule that restricts verbs.
• If the 405 is on OPTIONS, treat it as a CORS preflight problem rather than a method problem: handle OPTIONS on that route and return the CORS headers.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Read the Allow header the 405 is required to send

# -i prints the response headers alongside the status
curl -i -X POST https://example.com/article/1
# HTTP/1.1 405 Method Not Allowed
# Allow: GET, HEAD, OPTIONS   <- the methods this URL accepts

Remove WebDAV on IIS so PUT and DELETE reach your app

<!-- web.config, inside <system.webServer> -->
<handlers>
  <remove name="WebDAV" />
</handlers>
<modules>
  <remove name="WebDAVModule" />
</modules>

Restrict or allow methods deliberately in nginx

location /api/ {
  # everything except GET and POST returns 405 here
  limit_except GET POST { deny all; }
  proxy_pass http://app;
}
# remove or widen this block if a valid verb is being refused

How to prevent 405 Method Not Allowed

A 405 on a form or an API endpoint is invisible to an ordinary uptime check, because the GET that a basic monitor sends is exactly the method that still works while every write is refused. Pulsetic checks your website and endpoints from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook the moment a URL stops returning the status code you expect. It measures what a real client sees from outside, so a route that quietly stops accepting submissions does not stay quiet.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• MDN: 405 Method Not Allowed
• RFC 9110: HTTP Semantics (15.5.6 405 Method Not Allowed)
• MDN: The Allow header
• RFC 9110: HTTP Semantics