-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
UnexpectedEof Error on HTTP/2 Requests with Rustls #3427
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
Comments
Hm, is this a regression? Did it happen in 0.14? |
I'm pretty sure I've seen it with 0.14 too: it's easier to tease out with v1, as concerns are better separated now(!). Lemme try to reproduce... |
Yeah, it's not a regression. This is a reproduction with 0.14: https://github.com/cablehead/hyper-with-tls/tree/main/hyper-0.14-rustls |
Well that's good at least. Is it only with curl? Or do other clients also see this? Are you able to enable |
I've put up the repro for v1, and turned on tracing here: https://github.com/cablehead/hyper-with-tls/tree/main/hyper-1.0.1-rustls These are the logs from
|
The first attempt with Safari (macOS), I got: |
I tried searching Does this happen with native-tls? It could also be that curl in this case is terminating the connection differently than Safari. |
I'm seeing pretty much the same thing with rustls + hyper v1, but I'm getting |
Here's the tracing logs for my issue: https://gist.github.com/Gelbpunkt/b0fb2063d198cbae23b93b678065f3c1 |
Just to reiterate, it was noticed earlier in the thread that this seems to occur with hyper v0.14 as well (so I've adjusted the title). Is this something new with rustls? Or with curl? |
Apologies if this is just noise, yet when using hyper 0.14 + hyper-rustls on a per-connection basis (so not with the connection-pooling Client API), I would have sockets which worked a few ms prior suddenly error when making a new request over HTTP1. Conn::read_head
received 0 bytes
parse eof
State::close_read()
parse error (connection closed before message completed) with 0 bytes was a log snippet I saved. I was unsure if this was my fault, as it worked fine with the Client API (though I did check my connecting-driving re: async and Drop), or hyper's, or the server I was connecting to. Now seeing this issue, I feel this anecdote may be relevant. |
Interesting.
I'll knock up a sample that uses |
@Gelbpunkt I haven't come across any issues with HTTP1 + rustls yet. Do you have a small repro? |
This is a quick sample with hyper v1 + native-tls: https://github.com/cablehead/hyper-with-tls/tree/main/hyper-1.0.1-native-tls (i've merged the above v1 + rustls and v0.14 + rustls samples under this same repo and updated the links to them above) With the
@seanmonstar I'm thinking my next best step is to close this issue, and create a new one against |
It'd reasonable to assume the evidence points there. If after reporting there, new evidence says it's in hyper, we can dig further over here! |
This removes all re-attempts present in monero-serai's RPC and is an attempt to narrow down the sporadic failures. Inspired by hyperium/hyper#3427
This removes all re-attempts present in monero-serai's RPC and is an attempt to narrow down the sporadic failures. Inspired by hyperium/hyper#3427
Returning with new information :) I raised the issue with rustls here: rustls/rustls#1635 @jsha added some good context:
And he's since opened a PR to add this documentation: https://github.com/rustls/rustls/pull/1637/files#diff-015212fe8ccad176046e9d830f1db1e9ddde16d0e922f3817f72c07e587c9e17R36 If I'm understanding things correctly, it seems like the bug ultimately lies with curl. TLS clients are expected to send a @djc suggests:
Which may be the most pragmatic thing. What are your thoughts @seanmonstar? If you think it's reasonable, I could take a shot at a PR for it. And in that case, any easy pointers your could throw my way would be appreciated :) Given we don't see it with HTTP/1.1, I wonder: could hyper already be doing this if all outstanding requests are closed for HTTP/1.1 🤔 |
This removes all re-attempts present in monero-serai's RPC and is an attempt to narrow down the sporadic failures. Inspired by hyperium/hyper#3427
This removes all re-attempts present in monero-serai's RPC and is an attempt to narrow down the sporadic failures. Inspired by hyperium/hyper#3427
This removes all re-attempts present in monero-serai's RPC and is an attempt to narrow down the sporadic failures. Inspired by hyperium/hyper#3427
Version
Platform
Description
When making successful HTTP/2 requests over TLS , the following server logs an UnexpectedEof error for each request:
I tried this code:
https://gist.github.com/cablehead/e24990e364ecb3e6028d5978acd0c1c9
I performed a request using:
This successfully returns "Hello world" from the server. However, the server prints out the following error on every successful request:
Using the
http1
builder with the same TLS wrapper does not exhibit this behavior, and neither does HTTP/2 without the TLS wrapper.The expected behavior is that no error should be logged when a request completes successfully.
The text was updated successfully, but these errors were encountered: