Release notes from uWebSockets

v20.75.0

2026-02-20T00:56:33Z

Adds UWS_USE_SIMDUTF for using simdutf instead of default Utf8 validation
Show method and URL in terminating error message
Fixes some compilation error for modern C++23 compilers
Adds secure reloading gzip file server example

v20.74.0

2025-02-21T15:47:14Z

Minor libdeflate correction

libdeflate is now compatible with uWS::DEDICATED_DECOMPRESSOR and will be used if (and only if) the WebSocket's negotiation downgraded to equivalent of uWS::SHARED_DECOMPRESSOR (client_no_context_takeover). This will boost performance when possible. Of course, uWS::SHARED_DECOMPRESSOR as decompressor will always use libdeflate.
In other cases, zlib will be used regardless.

v20.73.0

2025-02-20T13:44:00Z

libdeflate as inflation ("decompression") fast path

Resurrecting support of libdeflate, now specifically only for inflation and only as a fast path to zlib.

WITH_LIBDEFLATE=1 make

builds examples using this fast path (you need to build the submodule first). Improved load_test.c benchmark can now highlight inflation cost:

For me and my particular test system:

With dynamically linked zlib - 110k msg/sec inflated and echoed 300 byte JSON messages
With statically linked zlib-cloudflare - 130k
With libdeflate as fast path - 180k
Without any inflation - 320k

Note: WITH_DEFLATE is only compatible with uWS::SHARED_DECOMPRESSOR!

v20.72.0

2025-01-28T14:40:37Z

Prepared Messages for Efficient Sending and Publishing

A feature from v0.14, previously removed due to lack of interest, has now been revived! Check out the demo in examples/Precompress.cpp to see it in action.

A PreparedMessage is a message that is compressed once but can be sent multiple times. This requires the SHARED_COMPRESSOR option but works with any decompressor option. The core idea is to decouple the compression process from the act of sending the message, reducing the per-socket computational overhead of compression to near zero.

Ideal Use Case

This feature is ideal for scenarios where you need to send snapshots of a data stream to multiple recipients. Here’s how it could work:

A timer periodically creates a new PreparedMessage containing the latest snapshot of the data (e.g., every 500ms).
When a WebSocket connects, it receives the most recent prepared snapshot, followed by incremental updates (deltas) from that point onward.
If the snapshot is large, pre-compressing it as a PreparedMessage eliminates the need for repeated compression, significantly reducing overhead for each socket.

Important Notes

This feature only works with SHARED_COMPRESSOR. Using a sliding window compression method is incompatible with this optimization.
New methods have been added to support this feature:
- WebSocket::sendPrepared
- App::publishPrepared
- Loop::prepareMessage
You can create PreparedMessage objects on any thread, as long as that thread has its own Loop (which is automatically created for you via Loop::get()). However, in such cases, you must handle synchronization manually. Refer to examples/Precompress.cpp for guidance.

This release introduces the interface and its initial implementation. While memory-saving optimizations are not included in this release, they may be addressed in future updates.

v20.71.0

2024-12-04T02:59:55Z

Examples are built in parallel
Supports building with all _LIBCPP_HARDENING_MODE
(Experimental) cached HTTP support is reverted for now, restoring fuzz builds
h1spec and test subject is added to CI
Disallow duplicate Host headers as per RFC9112

v20.70.0

2024-10-26T21:18:17Z

More HTTP testing & corrections

This release adds more HTTP tests and makes some minor corrections for passing those tests:

v20.69.0

2024-10-25T21:14:24Z

HTTP spec. compliance testing

A basic HTTP RFC9112 spec. compliance test has been added and minor changes have been made to pass all tests immediately:

This basic test catches no issues in Node.js, but it catches 2 issues in Deno (reported). The test can be found here:

https://github.com/uNetworkingAB/h1spec

In contrast, running the test on completely broken servers like mrhttp you get an obvious indication of so:

v20.68.0

2024-10-21T10:47:33Z

Improved (restored) backwards compatibility

For some users, recent introduction of CachedApp broke seamless backwards compatibility. If you rely on uWS::App being uWS::TemplatedApp<false> and not something else (like uWS::CachedApp<false> 😉), this release fixes your build:

    typedef uWS::TemplatedApp<false> App;
    typedef uWS::TemplatedApp<true> SSLApp;

v20.67.0

2024-09-24T06:18:40Z

Adds removeChildApp

v20.66.0

2024-09-11T16:18:46Z

Minor HTTP corrections

Emit 431 on too many headers (not just too long headers)
Don't emit 505 on fragmented request line (regression since 505 was introduced)