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

[pull] master from websockets:master #141

Open
wants to merge 275 commits into
base: master
Choose a base branch
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Oct 22, 2020

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

On Node.js >= 14.3.0 `request.abort()` does not destroy the socket if
called after the request completed.

Fixes #1869
The Node Security Platform service no longer exists. New security
advisories will be published to GitHub Security Advisories.
A specially crafted value of the `Sec-Websocket-Protocol` header could
be used to significantly slow down a ws server.

PoC and fix were sent privately by Robert McLaughlin from University of
California, Santa Barbara.
Rename `ca1-cert.pem` to `ca-certificate.pem`, `ca1-key.pem` to
`ca-key.pem`, `agent1-cert.pem` to `client-certificate.pem`, and
`agent1-key.pem` to `client-key.pem`.
lpinca and others added 5 commits May 29, 2021 21:21
Instead of destroying the socket, try to close the connection cleanly
if an error (such as a data framing error) occurs after the opening
handshake has completed.

Also, to comply with the specification, use the 1006 status code if no
close frame is received, even if the connection is closed due to an
error.

Fixes #1898
Call `ws.terminate()` only if `duplex.destroy()` is called directly by
the user and not indirectly by the listener of the `'error'` event of
the `WebSocket` object. Calling `ws.terminate()` right after the
`'error'` event is emitted on the `WebSocket` object, might prevent the
close frame from being sent to the other peer.
Use a pool of random bytes to reduce the amount of
`crypto.randomFillSync()` calls.

Refs: nodejs/undici#3204
It is possible that the Upgrade header is correctly received and handled
(the `'upgrade'` event is emitted) without its value being returned to
the user. This can happen if the number of received headers exceed the
`server.maxHeadersCount` or `request.maxHeadersCount` threshold. In this
case `incomingMessage.headers.upgrade` may not be set.

Handle the case correctly and abort the handshake.

Fixes #2230
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ pull merge-conflict Resolve conflicts manually
Projects
None yet
Development

Successfully merging this pull request may close these issues.