You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>404 Not Found</title>
</head>
<body align="center">
<div align="center">
<h1>404: Not Found</h1>
<p>The requested resource could not be found.</p>
<hr />
<small>Rocket</small>
</div>
</body>
</html>
however, since the passed URL is correct and only the method (verb) is wrong, according to rfc7231#section-6.5.5, it should return 405: Method Not Allowed with an Allow header field in a 405 response containing a list of the target resource's currently supported methods.
So, if you don't agree with that, could you provide a global option to send 405 instead of 404 for handling method not allowed errors?
TIA
The text was updated successfully, but these errors were encountered:
When a request method is received that is known by an origin
server but not allowed for the target resource, the origin server
SHOULD respond with the 405 (Method Not Allowed) status code.
I sounds like a good idea to default to 405 instead of 404, then - and applications that want a 404 can add a 405 catcher that returns a 404.
Hi.
Consider the following route:
now, if you call it with:
it returns:
however, since the passed URL is correct and only the method (verb) is wrong, according to rfc7231#section-6.5.5, it should return
405: Method Not Allowed
with anAllow
header field in a405
response containing a list of the target resource's currently supported methods.So, if you don't agree with that, could you provide a global option to send
405
instead of404
for handlingmethod not allowed
errors?TIA
The text was updated successfully, but these errors were encountered: