[Libwebsockets] v2.0 coming very soon
andy at warmcat.com
Tue May 17 19:53:29 CEST 2016
On May 18, 2016 12:23:21 AM GMT+08:00, Thomas Spitz <thomas.spitz at hestia-france.com> wrote:
>Everything works fine with lwsws top level function.
>This has shown me several interesting functions I would like to use but
>without activating libev/libuv (I am on a restricted resources embedded
>system) and without implementation new plugin approach (I am the only
With plugins, you don't need to write any serving code. Because all the features are anyway in lws, actually lwsws as the server only costs 16KB of .text.
Libuv isn't so cheap (you might be able to chop it down by configuring it for just file / loop / socket apis) but it buys you the ability to deploy the same generic and well-encapsulated plugin on other OSes with just a recompile. If it's not interesting, you're free to not use it, at the cost of losing plugins.
>- Redirect certain http port to https port
>- Use cgi (namely cgitest)
>- mountpoint to different system folder (egg: server-status redirects
>I suppose that the above functions are not tied to lwsws but I managed
>make it work neither with ./libwebsockets-test-server nor with
>./libwebsockets-test-server-v2.0 (plugin activated)
When we say 'it' work with test-server-v2.0.c what are we talking about? That code basically shows how to emulate lwsws using static data instead of JSON config. Everything lwsws does can be done that way; lwsws is more or less just a JSON parser for the config files that uses lws apis to get anything done. All the actual features are in lws.
>All other functions are working (Dumb Increment Demo, Mirror demo,
>testing, server info, post).
>By the way:
>- is it possible (easily) to restrict access (ask for login/pwd) for
>files/folders retrieved by HTTP like Apache do with .htpasswd?
No, but I expect I will need a generic per-vhost auth cookie / login thing soon. The auth cookie hash (kept persistently by the server side) would be associated with settable server-side attributes that could be tested by mounts to decide authorization for their bit of the url space.
>- I have seen "Lws platform-independent file access apis" but is it
>with any third party websocket client library? I suppose not...
I don't understand what you're asking.... what that does is let you intercept lws file operations at a low level in lws user code. Nothing above open / read etc file operations knows it exists.
>Sorry for so many general questions.
>2016-05-17 16:05 GMT+02:00 Andy Green <andy at warmcat.com>:
>> On May 17, 2016 9:29:07 PM GMT+08:00, Andy Green <andy at warmcat.com>
>> >On May 17, 2016 8:43:15 PM GMT+08:00, Thomas Spitz
>> ><thomas.spitz at hestia-france.com> wrote:
>> >>Everything work fine except cgitest (the test you explained here :
>> >Right, but I didn't put cgitest in the conf.d example.
>> >If I understood it, you can reproduce the conf.d example as it is
>> I added the test cgi script to the example localhost config at
>> The test script issues headers to set the output to text/html and
>> sends a html table of /proc/meminfo.
>> Managing spawned cgis has a quirk, to make it work reliably the
>> process is detached from the controlling terminal when spawning the
>> If you run lwsws in daemon mode, which is how the systemd integration
>> works, that doesn't make a problem and everything is normal. But if
>> it means after running the cgi, ^C from the controlling tty won't
>> lwsws. It's not that lwsws ignores it, it's not attached to the
>> any more in a way that receives the signal.
>> You can send it a SIGINT another way, like sudo killall -SIGINT lwsws
>> it will close fine. But if you're planning on using cgi, you should
>> lwsws as a daemon.
>> There's example systemd integration provided
More information about the Libwebsockets