![]() Add generic http compression layer eanbled at cmake with LWS_WITH_HTTP_STREAM_COMPRESSION. This is wholly a feature of the HTTP role (used by h1 and h2 roles) and doesn't exist outside that context. Currently provides 'deflate' and 'br' compression methods for server side only. 'br' requires also -DLWS_WITH_HTTP_BROTLI=1 at cmake and the brotli libraries (available in your distro already) and dev package. Other compression methods can be added nicely using an ops struct. The built-in file serving stuff will use this is the client says he can handle it, and the mimetype of the file either starts with "text/" (html and css etc) or is the mimetype of Javascript. zlib allocates quite a bit while in use, it seems to be around 256KiB per stream. So this is only useful on relatively strong servers with lots of memory. However for some usecases where you are serving a lot of css and js assets, it's a nice help. The patch performs special treatment for http/1.1 pipelining, since the compression is performed on the fly the compressed content-length is not known until the end. So for h1 only, chunked transfer-encoding is automatically added so pipelining can continue of the connection. For h2 the chunking is neither supported nor required, so it "just works". User code can also request to add a compression transform before the reply headers were sent using the new api LWS_VISIBLE int lws_http_compression_apply(struct lws *wsi, const char *name, unsigned char **p, unsigned char *end, char decomp); ... this allows transparent compression of dynamically generated HTTP. The requested compression (eg, "deflate") is only applied if the client headers indicated it was supported, otherwise it's a NOP. Name may be NULL in which case the first compression method in the internal table at stream.c that is mentioned as acceptable by the client will be used. NOTE: the compression translation, same as h2 support, relies on the user code using LWS_WRITE_HTTP and then LWS_WRITE_HTTP_FINAL on the last part written. The internal lws fileserving code already does this. |
||
---|---|---|
cmake | ||
contrib | ||
doc-assets | ||
lib | ||
lwsws | ||
minimal-examples | ||
plugin-standalone | ||
plugins | ||
READMEs | ||
scripts | ||
test-apps | ||
win32port | ||
.gitignore | ||
.mailmap | ||
.travis.yml | ||
appveyor.yml | ||
changelog | ||
CMakeLists.txt | ||
component.mk | ||
Kconfig | ||
libwebsockets.dox | ||
LICENSE | ||
Makefile.projbuild | ||
README.md |
News
v3.0.0 released
See the changelog for info https://libwebsockets.org/git/libwebsockets/tree/changelog?h=v3.0-stable
Major CI improvements for QA
The Travis build of lws done on every commit now runs
Tests | Count | Explanation |
---|---|---|
Build / Linux / gcc | 14 | -Wall -Werror cmake config variants |
Build / Mac / Clang | 14 | -Wall -Werror cmake config variants |
Build / Windows / MSVC | 7 | default |
Selftests | openssl:33, mbedtls:33 | minimal examples built and run against each other and remote server |
attack.sh | 225 | Correctness, robustness and security tests for http parser |
Autobahn Server | 480 | Testing lws ws client, including permessage-deflate |
Autobahn Client | 480 | Testing lws ws server, including permaessage-deflate |
h2spec | openssl:146, mbedtls:146 | Http/2 server compliance suite (in strict mode) |
h2load | openssl:6, mbedtls:6 | Http/2 server load tool (checks 10K / 100K in h1 and h2, at 1, 10, 100 concurrency) |
h2load SMP | 6 | Http/2 and http/1.1 server load checks on SMP server build |
The over 1,500 tests run on every commit take most of an hour to complete. If any problems are found, it breaks the travis build, generating an email.
Current master passes all the tests and these new CI arrangements will help keep it that way.
Lws has the first official ws-over-h2 server support
There's a new standard on the RFC track that enables multiplexing ws connections over an http/2 link. Compared to making individual tcp and tls connections for each ws link back to the same server, this makes your site start up radically faster, and since all the connections are in one tls tunnel, with considerable memory reduction serverside.
To enable it on master you just need -DLWS_WITH_HTTP2=1 at cmake. No changes to existing code are necessary for either http/2 (if you use the official header creation apis if you return your own headers, as shown in the test apps for several versions) or to take advantage of ws-over-h2. When built with http/2 support, it automatically falls back to http/1 and traditional ws upgrade if that's all the client can handle.
Currently only Chrome Canary v67 supports this ws-over-h2 encapsulation (chrome
must be started with --enable-websocket-over-http2
switch to enable it currently)
but the other browsers will catch up soon.
New "minimal examples"
https://libwebsockets.org/git/libwebsockets/tree/minimal-examples
These are like the test apps, but focus on doing one thing, the best way, with the minimum amount of code. For example the minimal-http-server serves the cwd on http/1 or http/2 in 50 LOC. Same thing with tls is just three more lines.
They build standalone, so it's easier to copy them directly to start your own project; they are CC0 licensed (public domain) to facilitate that.
Windows binary builds
32- and 64-bit Windows binary builds are available via Appveyor. Visit
lws on Appveyor,
click on a build, the ARTIFACTS, and unzip the zip file at C:\Program Files (x86)/libwebsockets
.
ESP32 is supported
ESP32 is now supported in lws! Download the
- factory https://warmcat.com/git/lws-esp32-factory/ and
- test server app https://warmcat.com/git/lws-esp32-test-server-demos
The ESP32 stuff has my dynamic mbedtls buffer allocation patches applied, which reduce allocation for small payload TLS links by around 26KiB per connection.
Support
This is the libwebsockets C library for lightweight websocket clients and servers. For support, visit
and consider joining the project mailing list at
https://libwebsockets.org/mailman/listinfo/libwebsockets
You can get the latest version of the library from git:
Doxygen API docs for master: https://libwebsockets.org/lws-api-doc-master/html/index.html