Date, Transfer-Encoding fixes

• The HTTP server now appends a valid "Date" header to responses.
• Fixes broken keep-alive for HEAD, OPTIONS, TRACE, CONNECT and DELETE methods introduced in v20.23.0 while adding chunked encoding support.

HTTP chunked transfer-encoding 🔪 🍰

• You can now send and receive data that is chunked according to Transfer-Encoding: chunked.
• Nothing changes from a user perspective; business as usual.

Dynamically removable HTTP routes and SNI domains

Together with the SNI improvements from v20.18.0 you can now add/remove HTTP routes dynamically, both for the root ("catch all") domain, and for any specific SNI domain.

If you added a route with

app.get("/hello", [](auto *res, auto *req) {

});

You now remove it with app.get("/hello", nullptr);

The same applies to routes added under a SNI name - browsing to the domain with app.domain("server_name") you can then remove the route added.

Note that you cannot remove WebSocket routes just yet (but doing so could make sense semantically).

• Fixes undefined behavior in App::removeServerName introduced in v20.18.0

Unix sockets

Thanks to @Young-Flash it's now possible to serve HTTP and WebSockets over Unix sockets - which interestingly works on all three platforms Windows, Linux, macOS 🤔

Improved SNI support

This is a backwards compatible change that detaches the URL router from the App, and moves it underneath the SNI support (if any). The new hierarchy is: App -> (SNI) -> URL router.

One App can have the root level SSL certificate and its URL routes, and/or many per-domain SSL certificates and their own isolated URL routes.

You "browse" between different SNI domains by calling the new function app.domain(server name) before calling app.get or app.post or any such route registration call. This can be chained together in builder pattern. Last "browsed to" SNI is under where you register the URL route handler.

See example ServerName for usage.

Improved HTTP timeout logic

When a client uploads (HTTP POST) a large file there has been a less-than-ideal timeout logic in uWS, where practically 0.1 byte/sec was enough to keep the connection open. This version bumps the required upload throughput to 16kB/sec as the lowest allowed. Any client uploading slower, will be dropped. You can configure the constant HTTP_RECEIVE_THROUGHPUT_BYTES as you wish.

HTTP/3 Cinema 🍿 📽️

While still highly experimental, the HTTP/3 support is now functional enough to stream a large video file correctly and without corruption. The video is shown being played by Firefox here, but has since also been tested to work with Chrome, curl and quiche-client.

This is a very visual milestone - it shows not only HTTP/3 working, but both HTTP/1 and HTTP/3 working together on the same thread. As you can see in the picture, an HTTP/1 server is used to instruct (at least Firefox?) the browser to go use the HTTP/3 one instead.

Experimental HTTP/3 via uWS::H3App

• Adds experimental uWS::H3App and example. With this type of app you can handle HTTP/3 requests with the same identical interface as for uWS::SSLApp, uWS::App. No code changes needed.
• This support is hidden under WITH_QUIC flag and entirely unsupported / for testing feedback / smoke testing only.
• Benchmarks are here.
• Working example is here.

How to test it

• This is experimental work entirely hidden under the WITH_QUIC make flag and disabled by default.
• Compile with WITH_BORINGSSL=1 WITH_QUIC=1 make and run the Http3Server binary. You can test it using quiche-client over IPv6 (you will need an IPv6 localhost address or else it will fail to listen). See Http3Server.cpp for an example quiche-client invocation.
• You first need to compile both lsquic and boringssl in respective git submodule paths. See their documentation for how to do this (it's pretty easy).