[Libwebsockets] How to make protocol_http support gzip

Andy Green 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[0] 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[0] 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[0] (and others if you want) instead of giving 
NULL for .protocols at vhost creation time.  Your protocols[0] would 
point to a callback which handles itself the external poll related 
reasons, and simply calls through to lws_callback_http_dummy() for the 
rest; and,

2) If you don't want runtime plugins, and have other protocols for ws 
support or whatever, you can also declare them as protocols[1] 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.


> Thanks!
> Chanson
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list