debuggability for parse errors?

Summary: as a hyper consumer, I'd love to be able to know when a server has encountered a parse error while reading a request so that we can report that to help people debug failures. Sorry in advance if this is possible already and I've missed it. I spent some time looking through discussions, issues, and the code, and I didn't find it. (I did find https://github.com/hyperium/hyper/discussions/2810, which made me think this probably isn't possible today.)

We're building a bunch of complex systems on top of Dropshot servers, which in turn are layered on hyper HTTP servers using the high level API. We've run into a few bugs recently where a server basically received garbage instead of a valid HTTP request. (Say, it got 6 zero bytes due to a bug in the kernel networking stack.) The failure mode is pretty tough to debug, especially after-the-fact. The client gets back a 400 "Bad Request" (which makes sense). There's nothing in the body saying what happened (also not unreasonable), but as far as I can tell there's no way for the hyper consumer (Dropshot in this case) to know that anything has happened.

We can snoop the network traffic to see what happened, but this requires problems to be pretty reproducible. They're often not. We'd really like to make this failure mode more debuggable after-the-fact.

Ideally we'd have a way of getting from hyper an Error object with a message like "expected HTTP header block, found 6 bytes: [ 0, 0, 0, 0, 0 0 ]". Even just "I got a malformed HTTP request on this connection" would be a big help. Maybe there could be an option for Service to accept Result<Request, SomeError> instead of just Request? We'd also be willing to use a lower-level API, but from what I can tell it doesn't look like this is exposed today even from hyper::server::conn::Http.

Start by reading the high-level Service API and the lower-level hyper::server::conn::Http entry point mentioned in the issue. Trace how malformed requests become a 400 response and determine where diagnostic information is lost. Done means the supported API exposes enough information for consumers to distinguish and report server-side parse errors.