HTTP2 CONNECT request with body creates undescriptive INTERNAL_ERROR error
#3858
Comments
|
Let's see if this PR has been repaired? Https://github.com/hyperium/hyper-util/pull/165 |
Running the provided example with: [patch.crates-io]
hyper-util = { git = "https://github.com/hyperium/hyper-util.git", rev = "d51318df3461d40e5f5e5ca163cb3905ac960209" }Does indeed change the flow, but results in the very same Error: |
|
This requires in-depth debug debugging to know the reason. In addition, it is effective for websocket upgrades or other protocol upgrades. You should also need to set up http2 extension protocol. https://github.com/hyperium/hyper-util/blob/master/tests/legacy_client.rs#L873C27-L873C31 And reqwest does not support the extension protocol of setting http2 for the time being. You need to fix it to test it. |
|
Are you sure hyper is detecting the error? That message, Most errors that |
|
Yes, pretty sure I would say. I included a backtrace print in the So originating from the line https://github.com/hyperium/hyper/blob/master/src/proto/h2/client.rs#L678. And that is exactly the weird thing, that that condition is checked at such a weird place and resulting in an |
|
Line 676 in 68bae2b
Didn't you send a body above? |
|
Oh I see, interesting. Yea we could improve that error message for sure. (As for why the warn isn't emitted, hyper's tracing is unstable, and requires opting into it.) |
seanmonstar
added
A-client
|
Ah nice, then everything makes perfect sense, thank you two for clarifying! As I see that you tagged this as easy, I might want to take a swing at fixing this later after work. |
|
Maybe we should add detailed error messages to the errors Line 679 in 68bae2b |
|
The action here I believe is to return a better error message. So, not necessarily force this to be a Right? The error is correct, the check should happen, it just leaves you confused? |
|
Yes, the error is correct, and the check should happen. I'm just confused on why the same request without TLS did not cause an error, which makes me wonder whether this is the right place to check this. But then I have no idea on the internal architecture of hyper, and also it's direct usage without a high level library such as reqwest. If not, I can just create a PR to add a more descriptive error to https://github.com/hyperium/hyper/blob/master/src/proto/h2/client.rs#L678. |
|
I would find it surprising if it skipped this check, I don't see anything in the surrounding code that would do so. Perhaps it's possible that when you force HTTP/2 without TLS, the server rejects that during the connection handshake, and so hyper never gets to the point of processing the request? But yes, the steps would be:
It probably doesn't need to be a |
|
I tried again with our application, which forces HTTP/2 without TLS, and the request goes through without the |
|
I found the issue. Checking a PCAP file of the request, it seems like HTTP2 was actually not enabled, and the requests were done with HTTP1.1. Changing that, I can also reproduce the So yep, everything is fine, and we only have to improve the error kind and message. |
Version
hyper: v1.6.0
hyper-tls: v0.6.0
hyper-util: v0.1.10
h2: v0.4.8
reqwest: v0.12.15
Platform
Linux workfedora 6.13.6-100.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 7 21:23:12 UTC 2025 x86_64 GNU/LinuxDescription
Hey, we recently stumbled across a weird undescriptive
INTERNAL_ERRORhyper error when using reqwest.We are writing a pentesting tool, and as a part of that we wanted to test whether a HTTP2 endpoint rejects invalid methods. As a part of that, we sent a CONNECT request, with a body.
That resulted in the error:
hyper_util::client::legacy::Error(SendRequest, hyper::Error(Http2, Error { kind: Reason(INTERNAL_ERROR) })) }It can be reproduced with:
Doing a bit of investigation with the backtrace crate, I gathered that the error originates from h2/client.rs.
Two weird things about that:
Log from example:
Not sure whether there is anything to fix / change here, we primarly wanted to report this.
The text was updated successfully, but these errors were encountered: