Puma sends empty response bodies even when low-level handler is specified

[cjlarose]

Describe the bug

Puma's README describes the lowlevel_error_handler as a way to specify how Puma should react in error conditions outside of the context of your application. Specifically, the docs show that you can return a Rack response with the expectation that Puma will write that response to the client socket.

In practice, though, Puma only writes that response in one particular kind of low-level error, server.rb:737. There are around six other places where the lowlevel_error_handler is invoked, but the return value is just discarded. In these cases, Puma writes the HTTP status line itself to the socket and closes it, without writing headers or a response body.

Since the lowlevel_error_handler is invoked in these cases, it's still better than nothing since application developers can still be notified of errors happening if they're reporting the error to their error collection system. But Puma offers no way to customize the response code, response headers, or response body in these cases. Clients just get blank responses.

Puma config:

lowlevel_error_handler do |e|
  puts "lowlevel_error_handler called"
  [500, {}, ["An error has occurred, and engineers have been informed. Please reload the page. If you continue to have problems, contact support@example.com\n"]]
end

Expected behavior

Puma writes the Rack response specified in the return value of the lowlevel_error_handler in every case that it's invoked.

Desktop (please complete the following information):

• OS: MacOS, Linux
• Puma Version: 4.3.5

[dentarg]

@cjlarose did you start on this? would be useful to be able to rescue Puma::HttpParserErrors IMHO and not have Puma log them (the requests are most often abuse)

[cjlarose]

Haven't started on this myself. I think when I wrote it up originally, my team was actually finding that puma was giving 5xx error responses to some machine clients (other services in our system), but our error tracker didn't have anything relevant. I think it was related to a problem with phased restarts.

What I want is to at least give the option to application developers to handle the error and respond with their own custom error response if they want. Right now, there a few places where application developers can't even hook into the errors and know that they're happening.

I agree it's normally misbehaving HTTP clients that causes these kinds of errors, but in some cases we've found that legitimate users can run into these problems and it'd be nice to be able to report them.

[dentarg]

Re-opening this issue as #2731 was reverted in #2809

[Vuta]

I took a stab at this here #3094. The approach is quite the same as #2731, except that I re-use the prepare_response method. Hence no changes in the Puma::Request module.
Let me know if there's anything else needed to be tackled.