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
HTTP parse error, malformed request (): #<Puma::HttpParserError: HTTP element REQUEST_PATH is longer than the 2048 allowed length (was 2459)>
I understand busting the 2048 limit is not very smart, but I think we should be able to catch those somehow. I did configure lowlevel_error_handler but this only catches errors from the Rack stack.
Currently the only solution I can think of is adding a Logentries alert matching Puma::HttpParserError. Would be better than nothing, yet I’d rather have those errors sent to Rollbar instead.
Is there any way to have those parser-level errors caught in Ruby land and reported to exception trackers?
If not, are there many other unlikely-yet-possible parser-level errors apart from REQUEST_PATH max length? Would it be wise to write them all somewhere in the Puma doc, or at least point to some files in the Puma .c/.java source where there are all located? Or as a last resort, suggest using a log-based monitoring solution like I described above?
The text was updated successfully, but these errors were encountered:
I’ve seen this error in our logs:
HTTP parse error, malformed request (): #<Puma::HttpParserError: HTTP element REQUEST_PATH is longer than the 2048 allowed length (was 2459)>
I understand busting the 2048 limit is not very smart, but I think we should be able to catch those somehow. I did configure
lowlevel_error_handler
but this only catches errors from the Rack stack.Currently the only solution I can think of is adding a Logentries alert matching
Puma::HttpParserError
. Would be better than nothing, yet I’d rather have those errors sent to Rollbar instead.Is there any way to have those parser-level errors caught in Ruby land and reported to exception trackers?
If not, are there many other unlikely-yet-possible parser-level errors apart from
REQUEST_PATH
max length? Would it be wise to write them all somewhere in the Puma doc, or at least point to some files in the Puma.c
/.java
source where there are all located? Or as a last resort, suggest using a log-based monitoring solution like I described above?The text was updated successfully, but these errors were encountered: