HTTP 405 Method Not Allowed – Free, Online, Private

What HTTP 405 means

405 says the method is not supported for this resource. The URL may be valid for GET and not for POST. The response must include an Allow header listing the methods that are supported. That header is the useful part. A 404 would hide the fact that the URL exists. Use 405 when existence is not a secret and the method is the problem.

405 Method Not Allowed belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 405

When you see HTTP 405 Method Not Allowed, stop on that exact status line. 405 Method Not Allowed means the URL exists and this method is not accepted. The trace that usually produces it: A client POSTed to a read-only URL. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 405 when the path is real and the method is not one you implement. Send Allow. Use 404 if you do not want to reveal the path. Use 501 if the method is not implemented anywhere on the server, as opposed to not allowed on this resource.

How to fix HTTP 405

To fix HTTP 405, change the condition that made the server choose Method Not Allowed. Read Allow and use one of those methods. Do not retry the rejected method. If Allow is missing, you have no machine-readable hint. Retrying the same method will fail. Retry only with a method listed in Allow. If the log line is a different code, leave this page. The mix-up people make with 405 is this one: 404 hides the resource. 501 means the server does not support the method at all. 400 means the request was malformed. 405 means the method is the mismatch.

• Allow was missing, so the client could not discover GET.
• A CORS preflight failed separately and the caller blamed 405 for an OPTIONS problem.
• A tunnel or proxy rejected the method before the application and invented a 405 without Allow.

An access log that only stores 405 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 405 Method Not AllowedHTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Allow lists GET and HEAD. The client should not POST again. HEAD should be listed if GET is listed, because HTTP requires HEAD support wherever GET is supported. The body can repeat the list for humans.

What the client should do

Read Allow and use one of those methods. Do not retry the rejected method. If Allow is missing, you have no machine-readable hint.

A 405 can be cached. If you later add POST, a cached 405 will hide it until it expires. Keep the lifetime short if the set of methods changes.

Retrying the same method will fail. Retry only with a method listed in Allow.

Codes people confuse with HTTP 405

404 hides the resource. 501 means the server does not support the method at all. 400 means the request was malformed. 405 means the method is the mismatch.