v20.66.0

User space cache for getRemoteAddress(), getRemoteAddressAsText() is now re-enabled after being extended to also support WorkerThreads. These calls are now zero-cost.

v20.65.0

The optimization introduced in v20.63.0 is not valid for Latin-1 strings; V8 does not store ASCII or UTF-8, it stores Latin-1 or UTF-16 or some rope combination of them. In v20.63.0, a Latin-1 stored V8 string will pop out as Latin-1 bytes, not the expected (implied) standard UTF-8, and there is no way to tell what uWS will give you.

This release removes the optimization for a conservative, always-UTF-8 output like before. It means uWS will always put UTF-8 bytes on the wire if the input was a JavaScript String.

v20.64.0

• Bumps uWS to v20.77.0 with important backpressure fix (see main repo for explanation)
• Reduces newly introduced (v20.63.0) 8MB thread-local pool size to 128kb
• Adds VideoStreamerChunked.js example with proper use of chunked transfer-encoding streaming

v20.63.0

Faster String arguments

With research & benchmarks done by @BV-WebDev, this release introduces optimizations for methods taking JavaScript Strings. The following demo runs with 17% higher req/sec overall, entirely due to this faster String argument passing:

get('/', (res, req) => {
  res.writeHeader("Hello", "There");
  res.writeHeader("Hi", "On you");
  res.end('Hello World!');
})

This optimization applies to Node.js 24 or later and relies on the new v8::String::ValueView.

v20.62.0

• Disables WebSocket.send V8 fastcall variant, suspected of causing issues for existing apps.
• Disables the UWS_REMOTE_ADDRESS_USERSPACE enabled in v20.61.0. There are cases where this feature is not fully implemented (such as use together with worker threads).

v20.61.0

10 years of uWS

If you are interested, there is a more detailed retrospect release post in the main repo. For Node.js we have the following changes:

• getRemoteAddress(), getRemoteAddressAsText() calls are now zero cost. This is a major performance boost for apps using these in hot paths.
• onDataV2 is a superior alternative to onData, explained in the linked retrospect release.
• collectBody is a helper function making optimal use of the new onDataV2. It allows efficient and easy collection of smallish HTTP posts into RAM, returned as one whole buffer.
• We now build AddressSanitizer binaries, available in branch binaries-asan. These can be very useful for debugging or filing bug reports related to crashes and segfaults. To run the ASAN binaries, your Node.js invocation needs to be prefixed with LD_PRELOAD like so: LD_PRELOAD=$(gcc -print-file-name=libasan.so) node server.js
• DeclarativeResponse can now do writeStatus as well as end with binary, not just text.
• Many documentation fixes.
• Support for symbol-keyed properties in WebSocket UserData.
• getRemotePort, getProxiedRemotePort.

v20.60.0

Bump lsquic

The experimental HTTP3 support is now building on latest lsquic 4.6.0.

v20.59.0

Following new BoringSSL versions

BoringSSL has deprecated their chromium-stable branch in favor of "date tagging". This version builds the recent 0.20260211.0 date tag.

v20.58.0

Easier URL route debugging

Whenever a URL route isn't handled properly, we used to display a fatal error and terminate the process like so:

Error: Returning from a request handler without responding or attaching an abort handler is forbidden!

This was not an issue in C++ since you could easily catch what route is broken by using a debugger. This is not possible in JavaScript since you aren't debugging the C++ code, only the JS code and the error isn't coming from JS.

A simple ergonomical upgrade is to display method & URL as part of the error:

Error: Returning from a request handler without responding or attaching an abort handler is forbidden!
        Method: "GET"
        URL: "/this_url_is_unhandled_test"
terminate called without an active exception

v20.57.0

• Fixes a bug in uWS.getParts where returned parts were previously zero-copy references into the given buffer. These parts are now copies, eliminating potential complex memory issues which shouldn't have been be exposed to script. uWS.getParts is not a streaming parser unlike most of uWS, so I would still caution against using it (even though it is faster than all other such parsers for Node.js given small files).