[Libwebsockets] How to make protocol_http support gzip
andy at warmcat.com
Fri Aug 4 00:24:20 CEST 2017
On 08/04/2017 02:41 AM, Chanson Shen wrote:
> Hi all,
> It seems both libwebsockets-test-server-v2.0 and lwsws use the .so in plugins directory to load plugins, but I noticed that there is no protocol_http in the plugin directory and two servers support HTTP and gzip.
That's right: what goes on there is if you don't provide ANY protocols
when you create a vhost (NULL .protocols), a dummy protocols callback
provided inside the library is used
this is exported from the library, so it's possible to provide protocols
and either point the protocols one yourself to
lws_callback_http_dummy(), or "subclass" lws_callback_http_dummy() by
handling some things and having the default: case call through to
> In my project, I need to use external poll and create my own session management, so I need to create a protocol_http and follow the framework of test-server.c and test-server-http.c. But how can my server support gzip in this case, it seems test-server-http.c does not support gzip.
These are actually a few unrelated things... unless I miss your point I
think there's no real problem here.
- don't be confused by the "plugins", they can be used as
runtime-discovered and loaded plugins, but they can also be statically
included. In v2.3, even the old style test-server mirror and server
status protocols are done using code from the "plugins" statically included
and the old, duplicated standalone implementations have been removed
(except dumb increment, so you can still see how to do it the old way).
- gzip support is provided by using a mount.
There is no hard and fast distinction between the old style and the
newer v2.0 features... you can declare mounts just fine when creating
the vhost even if the rest of your code is old style. (You will also
need LWS_WITH_ZIP_FOPS=1 at cmake and provide it libz-dev / zlib-devel
or whatever your distro calls it.)
- In most cases people should use the new style or as much of it as
possible; the old style is all about doing everything by hand in the
user code which is no longer necessary in most cases. Basically the old
style is the worst case where you provide everything manually, and lwsws
is the best case where you only write plugin code because every other
server function is provided generically already.
Throwing all the details into the user callback for eg, http makes it
difficult to see what is going on and to maintain it. The "v2.0" style
eliminates almost all the code in the test app and the plugins are very
focused and easy to maintain, eg,
In your case you should be able to follow the test-server-v2.0 example, but
1) provide a protocols (and others if you want) instead of giving
NULL for .protocols at vhost creation time. Your protocols would
point to a callback which handles itself the external poll related
reasons, and simply calls through to lws_callback_http_dummy() for the
2) If you don't want runtime plugins, and have other protocols for ws
support or whatever, you can also declare them as protocols etc same
as the old style test-server. It's highly recommended to split your
protocols out into "plugin style" sources even if you will statically
include them, not only for the maintainability but because it leaves the
door open to building them as plugins at a later date.
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets