-
Notifications
You must be signed in to change notification settings - Fork 545
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
feat!(H2): enable H2 by default #3814
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with it being enabled by default for fetch. Though I don't think it provides any meaningful advantage outside of fetch.
My thoughts on this is that it benefits mostly the use-cases that requires usually network calls to the internet (basically in the wild), as its where most of the HTTP/2 interactions happen. Fetch sadly does not really benefits from it as is not totally capable of handling H2 headers accordingly (and based on its semantics it seems mostly modeled around H1 in mind). The benefit I see on enabling it is for the uses cases previously mentioned, but it would beup to the server to decide which protocol to use. On top, this will only have visible effects on TLS connections, as we do not support h2c; for instance in a good majority of cases H1 will prevail. Maybe worth to document more of its intricacies just to put users aware? |
How? Are you saying that a |
Nop, fetch works with H2 regardless. What I am referring to with incompatibilities is that fetch does not handle several concepts of H2 (e.g. pseudo headers handling, does not fail but we do not parse these headers for the Headers map) |
THis seems a bit of a blocker of enabling this by default. Can you make some example? And possibly open PRs to handle those. |
I remember we have a chat about that on Fetch some time back, along with @KhafraDev regarding the handling of the pseudo headers; we didn't do it back then due to the spec, but if we are willing to explore that, happy to address it |
Although, worth mentioning that often than not the pseudo headers are of not much usage for the client; but still have seen some interests in having them available |
Can you make an example? I think that |
@metcoder95 could you implement these undici/lib/dispatcher/client-h2.js Lines 535 to 545 in 2252554
push , you should just disable it when connecting (https://nodejs.org/api/http2.html#settings-object).
|
Sure, let me check that; I'll go back on these over the week, still catching up after holidays. |
Disregard my last point about Opened #3854 for support of timeout and trailers. Will add some docs to this PR for what we discussed here |
This relates to...
Enable HTTP/2 support by default.
Rationale
After a chat with @mcollina, we have noticed that the most important pieces for HTTP/2 to work within Undici has been already implemented.
The number of issues and bugs has been reduced since the implementation of the feature, and now the HTTP/2 client is fully onboarded into the Undici's queue system.
Given that the adoption seems good and stable, I propose to enable the H2 by default for the upcoming major release.
Changes
Features
Bug Fixes
Breaking Changes and Deprecations
Status