Temporarily remove HTTP/2 support with Hyper #12191
Conversation
jsha
force-pushed
the
no-http2-hyper
branch
2 times, most recently
from
5216ef2
to
d8b89d1
Compare
|
Having some trouble with the test failures. Here are the tests that are failing: When I run them locally, though, they pass (with Hyper enabled). Five out of those seven verify stderr output. For instance, case 728 when failing in CI shows this diff: In other words, it expected just the error about SOCKS5 to appear on stderr, but additionally stderr has a warning "option CURLOPT_HTTP_VERSION returned error (1)". It seems pretty clear the failures are related to this branch (they only show up for the Hyper CI task), but I'm not yet sure what causes them. |
|
Ok, I got the Linux / hyper build to pass. Now what's failing is AppVeyor / autotools and AppVeyor / winbuild, which I think are flaky? At any rate I think this is ready for review. |
Yes, the AppVeyor ones are unfortunately flaky. Nothing related to this PR. |
There was a problem hiding this comment.
Do I understand it correctly that this PR then makes #11203 work "fast", just not using HTTP/2?
While it seems a little like a step backwards, I also realize that the current way we use the hyper API is wrong so this might be appropriate short term fix while we try to get a better understanding how the API should be used.
Nit: add a mention of this to docs/HYPER.md to help the next fellow hyper-in-curl hacker.
Yep, that's correct.
Done. |
docs/HYPER.md
Outdated
| @@ -57,6 +57,10 @@ The hyper backend does not support | |||
| - leading whitespace in first HTTP/1 response header | |||
| - HTTP/0.9 | |||
| - HTTP/2 upgrade using HTTP:// URLs. Aka 'h2c' | |||
| - HTTP/2 in general. Hyper has support for HTTP/2 but the curl side | |||
| needs changes so that a hyper_clientconn can last for the duration | |||
There was a problem hiding this comment.
| needs changes so that a hyper_clientconn can last for the duration | |
| needs changes so that a `hyper_clientconn` can last for the duration |
This should make the spellchecker happy.
The current design of the Hyper integration requires rebuilding the Hyper clientconn for each request. However, building the clientconn requires resending the HTTP/2 connection preface, which is incorrect from a protocol perspective. That in turn causes servers to send GOAWAY frames, effectively degrading performance to "no connection reuse" in the best case. It may also be triggering some bugs where requests get dropped entirely and reconnects take too long. This doesn't rule out HTTP/2 support with Hyper, but it may take a redesign of the Hyper integration in order to make things work.
The current design of the Hyper integration requires rebuilding the Hyper clientconn for each request. However, building the clientconn requires resending the HTTP/2 connection preface, which is incorrect from a protocol perspective. That in turn causes servers to send GOAWAY frames, effectively degrading performance to "no connection reuse" in the best case. It may also be triggering some bugs where requests get dropped entirely and reconnects take too long.
This doesn't rule out HTTP/2 support with Hyper, but it may take a redesign of the Hyper integration in order to make things work.
Partial fix for #11203