405 Error Explained: Causes, Fixes, and Prevention Tips

Every HTTP status code tells a story about what's happening between a client (e.g. web browser) and a server. Some stories are simple; 200 means success, 404 means the page doesn't exist. But when you see 405 Method Not Allowed, the story is a little more interesting.

Let's break down what the 405 error means, why it happens, and how to troubleshoot it

What the 405 Status Code Means

The 405 Method Not Allowed response happens when a client (like your browser or an API tool) makes a request using an HTTP method that the server does not allow for that resource.

For example:

• A form submission sends a POST request, but the server only accepts GET for that URL.
  
• A script sends a PUT request, but the endpoint is configured to only allow POST and DELETE.

The important detail is that the page you're trying to reach exists, but the request method used to interact with it is not permitted by the server.

What Might Cause a 405 Error

The 405 error doesn't always have a single, obvious cause. It can come from the way a request is made, how the server is configured, or even from extra security layers in place. Here are the most common situations that would trigger it:

1. Wrong HTTP Method

Every resource on a server is set up to accept certain HTTP methods. For example:

• A product page might allow GET (to fetch details) but reject POST (to submit data).
  
• An API endpoint might allow POST to create a new item but return a 405 if you try DELETE.

A common scenario is when a developer sends a POST request to a URL that was only designed to handle GET. The server recognizes the resource, but since the method isn't supported, it responds with 405.

This is one of the most frequent causes, especially when working with forms, APIs, or scripts that interact with web services.

2. Misconfigured Server Rules

Web servers like Apache, Nginx, and IIS give administrators control over which HTTP methods are allowed. Configuration directives such as Apache's Limit or Nginx's limit_except can explicitly block certain verbs.

For instance:

• A server admin might configure a site to only allow GET and POST, blocking PUT and DELETE for security.
  
• If the rules are too strict (or miswritten), legitimate requests can be rejected with a 405.

This can often happen after changes to .htaccess files, server blocks, or IIS request filtering settings. Even a small typo or overlooked directive can result in methods being unintentionally blocked.

3. API Restrictions

APIs are designed with strict method rules. In a RESTful API, different HTTP verbs usually correspond to specific actions:

• GET → Retrieve data
  
• POST → Create new data
  
• PUT/PATCH → Update existing data
  
• DELETE → Remove data

If a developer calls an endpoint with the wrong method, such as sending a PUT to a URL that only allows POST, the server responds with a 405.

This is intentional, as APIs are meant to enforce consistent interaction patterns. For example, GitHub's API won't let you DELETE a repository by mistake through a wrong method call, it requires the correct verb, or you'll get a 405 response.

4. Incorrect Form or AJAX Setup

Web forms and JavaScript (AJAX) requests are another common source of 405 errors:

• A form might have the method="post" attribute, but the server only allows GET on that URL.
  
• JavaScript's fetch() or XMLHttpRequest may be coded to send a PUT request when the backend only supports POST.

Since browsers handle form and AJAX submissions automatically, even a small mismatch in how a request is coded versus how the server expects it can trigger this error.

Beginners often encounter this when learning to set up forms in PHP or when working with frontend frameworks that make API calls.

5. Security Tools

Even when a server is configured correctly, security layers can step in and block requests. Examples include:

• Web Application Firewalls (WAFs): These monitor incoming traffic and may reject methods like PUT, DELETE, or TRACE to reduce the risk of attacks.
  
• Security Plugins: In platforms like WordPress, some plugins disable certain methods site-wide to prevent unauthorized requests.

In these cases, the server itself might support the method, but the request gets intercepted before it reaches the application. This often leads to confusion because logs may show the server "rejecting" the method when in reality it's a security layer doing the filtering.

How 405 Differs From Similar Status Codes

At first glance, the 405 error can be mistaken for other client and server errors. But the details matter, and knowing the differences will help you diagnose it correctly.

404 Not Found

• What it means: The server can't find the resource you're requesting.
  
• Example: You try visiting example.com/page.html, but the page doesn't exist at all.
  
• Key difference from 405: With a 404, the problem is the resource itself not being there, whereas with a 405, the resource exists—you're just using the wrong method to interact with it.

403 Forbidden

• What it means: The resource exists, but the server is blocking you from accessing it.
  
• Example: You may be trying to view a private directory without proper permissions.
  
• Key difference from 405: A 403 is about access rights, while a 405 is about method restrictions.

501 Not Implemented

• What it means: The server doesn't recognize or support the HTTP method at all, for any resource.
  
• Example: A server that doesn't support PATCH requests will throw this error no matter what resource you try.
  
• Key difference from 405: A 501 applies to the entire server, while a 405 applies only to a specific resource.

Diagnosing the 405 Error

It can be tricky to diagnose the 405 because the server is acknowledging the resource exists, but it's refusing to process the request the way it was sent. To track down the root cause, it helps to work through the problem step by step.

1. Check the Allowed Methods

When a server returns a 405, the response should include an Allow header listing which methods are supported for that resource. This is the server's way of saying, "You can't do that, but here's what you can do."

Example:

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST

• If you tried PUT, this response tells you that only GET and POST are valid.
  
• You can see this using browser developer tools (Network tab) or a tool like Postman.
  
• Automating header checks in a debugging workflow can quickly highlight misaligned method usage across multiple endpoints.

2. Review Server Logs

Logs are often the fastest way to uncover the cause as they will typically give a direct explanation of why the request was rejected and confirm it isn't a deeper connectivity issue.

• Apache: Check the error_log file, usually in /var/log/apache2/ or /var/log/httpd/.
  
• Nginx: Review error.log and access.log, usually in /var/log/nginx/.
  
• IIS: Open Event Viewer or check IIS log files under %SystemDrive%\inetpub\logs\LogFiles\.

Logs may show entries like:

client sent an unsupported method (PUT) to /index.php

3. Test the Endpoint

Tools like cURL or Postman are invaluable for confirming which methods actually work. Testing endpoints this way rules out guesswork and gives you clear visibility into how the server responds to different requests.

Using cURL:

curl -i -X GET https://example.com/resource
curl -i -X POST https://example.com/resource
curl -i -X PUT https://example.com/resource

• If GET and POST succeed but PUT fails with a 405, you've identified the mismatch.

Postman gives a visual interface where you can toggle request methods and instantly see responses, making it more beginner-friendly.

4. Check Your Code

If the server allows the method but you're still getting a 405, the problem may be in your application code.

Forms: Make sure the <form> element's method attribute matches what the server expects. Example:

 <form action="/submit" method="post">

AJAX/Fetch: Verify that the request method is set correctly in JavaScript:

 fetch('/api/data', {
  method: 'POST'
})

• Frameworks: Some frameworks (like Angular, React, or Django) may default to certain methods if you don't explicitly set them. Double-check your client-side and server-side code for mismatches.

Note: This step is often where beginners get tripped up, sending data to the right endpoint but with the wrong verb.

5. Examine Server Configuration

If both headers and code look fine, the issue may be server-level restrictions. Admins often block methods for security reasons, but if legitimate requests are being stopped, adjusting these settings is necessary.

Apache: Look for Limit or LimitExcept directives in your .htaccess or main config. Example:

 <Limit GET POST>
   Require all granted
</Limit>

• If PUT is missing here, any PUT request will return a 405.

Nginx: Check limit_except directives:

 location /api/ {
   limit_except GET POST {
      deny all;
   }
}

• This would reject methods other than GET and POST.
  
• IIS: Open the IIS Manager, go to Request Filtering, and review the HTTP Verbs tab. Blocked verbs like PUT or DELETE will show up here.

Fixing a 405 Error by Platform/Environment

Fixing a 405 error depends on the platform or environment your website or application is running on. Since each server type and content management system handles HTTP requests differently, the solution can vary. Let's go over some common platforms and walk through the steps we can take to review configurations and adjust settings so the correct HTTP methods are allowed.

Quick pre-check (applies to all)

1.Reproduce the error and read headers

curl -i -X PUT https://example.com/path

2. If you see Allow, adjust your request/client to match. If you don't, continue below.

Apache

1.Locate config

• Site config: /etc/apache2/sites-available/*.conf or /etc/httpd/conf.d/*.conf
  
• Per-dir rules: project .htaccess

2. Back up the file you'll edit

sudo cp /etc/apache2/sites-available/site.conf /etc/apache2/sites-available/site.conf.bak

3. Search for method restrictions

• Look for <Limit ...>, <LimitExcept ...>, or RewriteRule patterns that block verbs.

# Example: only GET/POST allowed here
<LimitExcept GET POST>
  Require all denied
</LimitExcept>

4. Add the needed method(s) or remove the restrictive block

<LimitExcept GET POST PUT>
  Require all denied
</LimitExcept>

5. Validate and reload

sudo apachectl -t
sudo systemctl reload apache2   # or: sudo systemctl reload httpd

6. Retest with curl

curl -i -X PUT https://example.com/path

7. If still blocked, check security layers (e.g., mod_security audit logs) and virtualhost precedence.

Nginx

1.Open the server block for your site

• Common paths: /etc/nginx/sites-available/, /etc/nginx/conf.d/*.conf

2. Back up the file

sudo cp /etc/nginx/sites-available/site.conf /etc/nginx/sites-available/site.conf.bak

3. Look for limit_except blocks

location /api/ {
  limit_except GET POST {
    deny all;
  }
}

4. Add the needed method(s) or remove the block if unnecessary

location /api/ {
  limit_except GET POST PUT {
    allow all;
  }
}

5. Test and reload

sudo nginx -t
sudo systemctl reload nginx

6. Retest with curl

curl -i -X PUT https://example.com/api/resource

7. If you proxy to an app server, confirm upstream also allows the method.

IIS (Windows Server)

1. Open IIS Manager → select the site.
   
2. Go to Request Filtering → HTTP Verbs.
   
3. Remove any Deny entries for verbs you need (e.g., PUT, DELETE) or add Allow entries if your policy requires explicit allows.
   
4. Check Handler Mappings: if WebDAV is installed and intercepting verbs you need, remove or disable the WebDAV handler for that site (or uninstall WebDAV if not needed).
   
5. If present, review web.config for:

<system.webServer>
  <handlers> ... </handlers>
  <security>
    <requestFiltering>
      <verbs>
        <!-- Remove Deny for verbs you need -->
        <add verb="PUT" allowed="true" />
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

6. Recycle the app pool or restart the site.

7. Retest with curl/Postman.

WordPress & other CMS platforms

1. Re-save permalinks
   • Settings → Permalinks → Save Changes (this refreshes rewrite rules).
2. Test for plugin conflicts
   • Temporarily disable all plugins.
     
   • Re-enable one by one to find the offender (security, REST/API, caching, and firewall plugins are common causes).
3. Check platform-generated rules
   • Apache: .htaccess sections added by plugins.
     
   • Nginx: server blocks added for caching/security that might contain limit_except or method filters.
4. If you use the CMS REST API, verify accepted methods on the endpoint and adjust the client or route config accordingly.
   
5. Retest key actions (forms, logins, admin actions) after each change.

APIs (general)

1.Confirm the contract

• Check the API docs for each endpoint's allowed methods and expected paths.

2, Probe the endpoint

# Discover allowed methods (if supported)
curl -i -X OPTIONS https://api.example.com/v1/items/123
# Then try the method you intend
curl -i -X PATCH https://api.example.com/v1/items/123

3. Fix client or server (examples)

• Client fix: send the method the endpoint actually supports (e.g., POST instead of PUT).
  
• Express (Node.js)

 app.post('/items', createItem);
app.put('/items/:id', updateItem);
// If PUT not defined, add it—or switch your client to POST if that's the design.

• Flask (Python)

 @app.route('/items/<id>', methods=['GET','POST','PUT','DELETE'])
def item(id): ...

4. Set a helpful 405 with Allow header (server-side)

• If your framework doesn't auto-set it, add the header listing permitted methods.

5. If fronted by an API gateway/WAF, review method filtering rules there as well.

6. Retest with Postman/curl and confirm the expected 2xx/3xx/4xx flow.

After the fix: quick verification list

• The action now returns a success or the correct error (not 405).
  
• Allow header accurately lists permitted methods.
  
• Logs show normal handling, not a blocked verb.
  
• Automated tests (if you have them) cover the corrected path and method.

Preventing 405 Errors in the Future

Fixing a 405 error when it appears is only half the challenge—preventing it from happening again is what saves you time and frustration in the long run. By putting the right practices in place during development and configuration, you can reduce the chances of users or applications running into unsupported methods. Here are several approaches that help keep 405 errors from becoming recurring problems.

Validate Methods in Code

When writing forms, scripts, or API calls, double-check that you're only using HTTP methods that the server allows. For instance, if your server accepts POST for submitting data, make sure you don't accidentally use GET or PUT. Validating methods early in development also helps catch mistakes before they reach production. Many frameworks let you define allowed methods directly in routes or controllers, making it easier to enforce correct usage.

Document Server Rules

Servers often have method restrictions defined in their configuration files (like .htaccess, nginx.conf, or API gateway settings). Keeping a record of what methods are supported makes it easier for both developers and administrators to understand the limits. This documentation is especially useful in larger teams or long-term projects, where server rules can otherwise get lost or forgotten over time.

Error Handling

Even with careful planning, unsupported method requests may slip through. That's why it's useful to provide clear error messages when a 405 occurs. Instead of a vague "Method Not Allowed," customize the response so the user or developer understands what went wrong and how to correct it—for example, by including the list of allowed methods in the response header or suggesting the right method in your documentation.

Follow Standards

If you're building APIs, sticking to REST best practices and HTTP standards makes it easier for clients to know what to expect. For example, if you design an endpoint for updating a resource, use PUT or PATCH consistently. This predictability reduces the risk of unsupported methods being sent and helps external developers interact with your API correctly.

Wrapping Up

The 405 Method Not Allowed error tells you that the server knows the resource exists, but it doesn't allow the method you tried.

The key takeaway: check the Allow header, review logs, and make sure your code and server rules match the methods you intend to support.