Skip to content
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

Improve HTTP server 'upgrade' event generation logic #57054

Open
mykola-mokhnach opened this issue Feb 14, 2025 · 0 comments
Open

Improve HTTP server 'upgrade' event generation logic #57054

mykola-mokhnach opened this issue Feb 14, 2025 · 0 comments
Labels
feature request Issues that request new features to be added to Node.js.

Comments

@mykola-mokhnach
Copy link

mykola-mokhnach commented Feb 14, 2025

What is the problem this feature will solve?

There is an interesting bug/limitation we've stumbled upon recently in the node.js's http server implementation.

We had the 'upgrade' event listener defined in our code to properly map web sockets, although this lead to an issue with HTTP/2 h2c upgrade requests.
Basically, the current logic to emit the 'upgrade' event only considers the presence of the Upgrade header for a particular request without verifying other values. Such approach causes the event to be also emitted for HTTP/2 upgrade requests, which have similar syntax to websocket upgrades, just the value of the Upgrade header differs.
In our case the presence of the upgrade event listener was always causing h2c upgrade requests to be unexpectedly rejected, while the expected behaviour would be to just downgrade the connection to HTTP/1.1.
A workaround to that was to remove the upgrade listener and add a http middleware instead, although this creates another bug where the server.requestTimeout is applied to web sockets created by such middleware. After the timeout is fired websocket connection is killed forcefully and there is no way to customize this behaviour.

See the issue appium/appium#20760 for more details and code examples

What is the feature you are proposing to solve the problem?

I expect there is a possibility to either be able to explicitly provide to which types of upgrade request the upgrade event must be triggered (e.g. only web socket upgrades)

OR

there is a possibility to continue handling the request as if no upgrade event has been defined (similarly to calling next() in a middleware handler), so I could default to HTTP/1.1 if I detect it's a h2c request type after checking the request headers (or any other non-websocket upgrade request)

OR

there is a possibility to remove requestTimeout from the particular socket if we upgrade it to a websocket in a middleware rather than via the upgrade event

What alternatives have you considered?

Unfortunately I am out of other options for now.

@mykola-mokhnach mykola-mokhnach added the feature request Issues that request new features to be added to Node.js. label Feb 14, 2025
@github-project-automation github-project-automation bot moved this to Awaiting Triage in Node.js feature requests Feb 14, 2025
@mykola-mokhnach mykola-mokhnach changed the title http 'upgrade' event must only be generated for websocket upgrades Improve HTTP server 'upgrade' event generation logic Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issues that request new features to be added to Node.js.
Projects
Status: Awaiting Triage
Development

No branches or pull requests

1 participant