Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debuggability for parse errors? #3225

Open
davepacheco opened this issue May 12, 2023 · 3 comments
Open

debuggability for parse errors? #3225

davepacheco opened this issue May 12, 2023 · 3 comments
Labels
C-feature Category: feature. This is adding a new feature.

Comments

@davepacheco
Copy link

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 #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.

@seanmonstar
Copy link
Member

I'm always interested in making debugging easier.

Is the issue here that the Connection didn't return an error at all? Or that it's error message is weak? Or would a log message have helped? Some combination of the above?

@davepacheco
Copy link
Author

The issue here was that we didn't get any error at all from hyper. (Again, sorry if I'm just missing the interface we should be using to get it. I just didn't see it.)

@davepacheco
Copy link
Author

Unrelated, but I just wanted to add: thanks for all the work on hyper! We've been using it (via Dropshot) fairly heavily in many components for about three years now (mostly still in the development phase). It's been solid for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature Category: feature. This is adding a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants