-
Notifications
You must be signed in to change notification settings - Fork 30k
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
http2: handle existing socket data when creating HTTP/2 server sessions #41185
http2: handle existing socket data when creating HTTP/2 server sessions #41185
Conversation
When emitting a 'connection' event to manually inject connections into a server, it's common for the provided stream to already contain readable data, e.g. after sniffing a connection to detect HTTP/2 from the initial bytes. Previously this was supported only for outgoing HTTP/2 sessions created with http2.connect(). This change ensures that HTTP/2 over existing streams is supported on both outgoing and incoming sessions.
Review requested:
|
The
|
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.
lgtm
FYI npm had an outage earlier today: https://status.npmjs.org/incidents/7klw65jd5f5r |
Landed in cadeabc |
When emitting a 'connection' event to manually inject connections into a server, it's common for the provided stream to already contain readable data, e.g. after sniffing a connection to detect HTTP/2 from the initial bytes. Previously this was supported only for outgoing HTTP/2 sessions created with http2.connect(). This change ensures that HTTP/2 over existing streams is supported on both outgoing and incoming sessions. PR-URL: #41185 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
When emitting a 'connection' event to manually inject connections into a server, it's common for the provided stream to already contain readable data, e.g. after sniffing a connection to detect HTTP/2 from the initial bytes. Previously this was supported only for outgoing HTTP/2 sessions created with http2.connect(). This change ensures that HTTP/2 over existing streams is supported on both outgoing and incoming sessions. PR-URL: #41185 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
When emitting a 'connection' event to manually inject connections into a server, it's common for the provided stream to already contain readable data, e.g. after sniffing a connection to detect HTTP/2 from the initial bytes. Previously this was supported only for outgoing HTTP/2 sessions created with http2.connect(). This change ensures that HTTP/2 over existing streams is supported on both outgoing and incoming sessions. PR-URL: nodejs#41185 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
When emitting a 'connection' event to manually inject connections into a server, it's common for the provided stream to already contain readable data, e.g. after sniffing a connection to detect HTTP/2 from the initial bytes. Previously this was supported only for outgoing HTTP/2 sessions created with http2.connect(). This change ensures that HTTP/2 over existing streams is supported on both outgoing and incoming sessions. PR-URL: #41185 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Fixes #34532 (maybe #29902 too, TBC)
When emitting a 'connection' event to manually inject connections into a server, it's common for the provided stream to already contain readable data, e.g. after sniffing a connection to detect HTTP/2 from the initial bytes.
Previously this was supported only for outgoing HTTP/2 sessions created with
http2.connect()
. This change ensures that HTTP/2 over existing streams is supported on both outgoing and incoming sessions.There was an attempt to fix this previously in #34958, which works! Unfortunately that was closed and replaced by #35678, which fixes the same issue but only for outgoing connections (by fixing
http2.connect
directly), not all HTTP/2 sessions.This PR takes the HTTP/2 test from #34958 (which covers the server case) and moves the fix from #35678 into the session so it applies to all HTTP/2 sessions.