Puma responds with a 501 Server Error when a client sends invalid HTTP methods
danielmconrad opened this issue · comments
When SUPPORTED_HTTP_METHODS was added to the codebase, Puma began responding with a 501 error when clients send in unknown or invalid HTTP methods.
Why this is problematic:
As is common on the web, bots will attempt to penetrate web applications by using rare or incorrect methods. This can result in applications throwing dozens or hundreds of 5xx errors, co-mingling with actual server errors that come from application code.
Proposed solution:
Simply respond with a 400 Bad Request or a 405 Method Not Allowed.
501 sounds like the correct one: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/501
We have history on this topic in #3014 and #3106
Since Puma 6.3.0 you can allow any method and let your app define the response (check the DSL docs)
I think Puma should change the default of the DSL option to any, so Puma behaves like Puma v5 did: #3014 (comment)
@nateberkopec are you willing to make a decision on this?
501 sounds like the correct one
Agree. See RFC9110 501 Not Implemented, which states:
This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
As to a change of default, don't feel strongly either way.
My suggestion above for 405 is likely not correct, since:
405 Method Not Allowed response status code indicates that the server knows the request method
We certainly don't know them in many cases. A few examples of the methods we see are, TRACK, MTJTSS, SSTP_DUPLEX_POST, and NYTVNJ.
As for 501, according to the notes on the page,
A 501 error is not something you can fix, but requires a fix by the web server you are trying to access.
This is definitely not something we, as "the web server", intend to fix, as the requests are obviously malicious. I suggested responses in the 4xx range mainly because of the industry norm to send 4xx when the client is at fault. Here's W3 on this topic:
The 4xx codes are intended for cases in which the client seems to have erred, and the 5xx codes for the cases in which the server is aware that the server has erred.
But to be fair, the next sentence is literally:
It is impossible to distinguish these cases in general, so the difference is only informational.
So, I see how the 501 would to make sense to keep consistency with RFC 9110, but I still don't think it does in our case. I think the spec is, at best, lacking in this area. For practical purposes, we would very much like to keep 5xx responses to a minimum. If changing the DSL allows us to do that, I'd say it's a great compromise.
If changing the DSL allows us to do that, I'd say it's a great compromise.
Not sure what you mean, but the comments/docs for DSL#supported_http_methods show that fairly finegrained control over what generates a 501 is available.
JFYI, the W3 link is very old.
@MSP-Greg My apologies, I wasn't aware of DSL#supported_http_methods. I'm happy to close this request.