Repository navigation
Conversation
With the uWebSockets.js server, the HttpRequest object must not be used once the route handler has returned. When a middleware (for example express-session with an existing session) or the allowRequest() option completes asynchronously, the handshake failed with: > uWS.HttpRequest must not be accessed after await or route handler return - for WebSocket upgrades, the Sec-WebSocket-* headers are now read synchronously, and the response is written within a cork() callback - for HTTP long-polling, the method is now read from the prepared request.method attribute instead of req.getMethod() Related: socketio#5330 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The kind of change this PR does introduce
Current behavior
With the uWebSockets.js server (
uServer), theHttpRequestobject must not be used once the route handler has returned. When a middleware or theallowRequest()option completes asynchronously, the request is still accessed afterwards, and the connection fails with:req.getHeader("sec-websocket-*")is called in the verify callback (and the response is written outside ofcork(), which logs "uWS.HttpResponse writes must be made from within a corked callback")req.getMethod()is called inPolling.onRequest()This happens for example with
express-sessionwhen the client already has a session cookie (the store lookup is asynchronous), which matches the reconnection scenario in #5330.New behavior
Sec-WebSocket-Key/Protocol/Extensionsheaders are read synchronously, and the status, headers andupgrade()call are made withinres.cork()req.method(already set inprepare()) instead ofreq.getMethod()Two tests were added in
test/middlewares.jswith a middleware that callsnext()in asetTimeout(). They fail withEIO_WS_ENGINE=uwsbefore this change and pass after it (they pass with the default engine both before and after).Other information (e.g. related issues)
Related: #5330 (the reporter describes the same two changes in
handleUpgrade).Not addressed here: a long-polling POST request still loses its body when a middleware is asynchronous, since
res.onData()is only attached after the middlewares have run. Buffering the body earlier looked like a bigger change, so I left it out.I used Claude Code to write this change.