v20.45.0

Default 404 page

This release adds another error page; the 404 File Not Found. Along with the recently added error codes, this should make it a lot easier to debug proxy issues / log misbehaving clients or the like.

Instead of simply getting a RST (which often times results in 502), proxies and end clients now get the proper 404 error code for any unhandled URL / method.

This new behavior can be tested by running the EchoServer example and requesting any HTTP page.

v20.44.0

HTTP error pages

NGINX is a silly proxy. It's very common for users to report issues with NGINX, and it's easy to understand. If you set up NGINX as proxy for uWS, you will most likely get a spinning wheel followed by 502 Bad Gateway as if the uWS server is unreachable.

This is because NGINX defaults to the 27 year old, ancient, HTTP/1.0 when talking to backend servers. uWS naturally does not support this protocol, and is only fully standards compliant with the 26 years younger HTTP/1.1 RFC9112.

However, ideology aside, it would be nice if uWS played along with existing ecosystems. Now it does:

This page is what you will see after setting up NGINX to proxy uWS. From this error it should hint of the proxy_http_version 1.1 config in NGINX. Once applied, the NGINX -> uWS combo will give you this:

You can see and configure the error pages in src/HttpErrors.h. More errors will be added as they are needed. The default style is a minimal Apache-like page.

v20.43.0

PROXY v2 support

• Restores function to this haproxy protocol, as broken by some refactor way back.

v21.0.0-alpha2

v21 and io_uring

With more features added, more optimizations and more examples working properly, here's the current performance metrics comparing uWS v21 against latest denoland/fastwebsockets v0.4.2. As an aside, uWS can now do URL routed HTTP requests at 350k req/sec, which is even faster than what an optimized epoll server can do raw TCP echoing (325k msg/sec) on this machine. Just think about that for a moment - uWS is serving standards compliant HTTP faster than you could do even raw TCP a few years ago. Mind blown.

v20.42.0

uWS never cared to optimize non-SSL, non-compressed semi-big WebSocket message sending, and so was a bit slower than what denoland/fastwebsockets v0.4.2 presented. This release adds such optimization and is now reliably and significantly faster in all cases.

Also, keep up to date for news on the v21 release where io_uring will be default and we see even bigger outperformance.

v21.0.0-alpha1

Linux 6.0+ io_uring as new backend

This alpha release adds initial (still to be further optimized) io_uring support in uWS. It is still very incomplete, but EchoServer, HelloWorld and even HelloWorldThreaded work. As do load_test and http_load_test and possibly other examples.

Here's a comparison against the (minimal) fastwebsockets project, and against uWS v20. We still have a bunch of optimizations to add, zero-copy for instance.

You can build it with LDFLAGS=/usr/lib/liburing.a WITH_IO_URING=1 make

v20.41.0

• Adds the Autobahn|Testsuite as an automatic test run by GitHub Actions, rather than manually.
• A WebSocket parser benchmark has been added.
• A few optimizations to the WebSocketProtocol.h.

v20.40.0

Fixes an edge case where URI querystrings with keys with no value gets interpreted as invalid querystring.

Now the querystring "?one=&two=hello%20world" is considered valid, and HttpRequest.getQuery("two") will return "hello world" like it should.

This release also adds testing for the above case.

v20.39.0

• Fixes a bug introduced in the bug fix of v20.38.0 🥇
• Adds new fuzz target for involved functionality

v20.38.0

Fixes an edge case where calling HttpResponse::upgrade inside HttpResponse::cork from inside a third-party callback would crash.

Full Changelog: v20.37.0...v20.38.0