[Libwebsockets] CGI + proxying update and lwsws

Andy Green andy at warmcat.com
Mon Mar 21 09:29:07 CET 2016

Hi -

Some updates on stuff of master first

1) The CGI support on master is now good enough to run cgit 
(https://git.zx2c4.com/cgit/) cgi, although out of the box it spawns a 
test script that sends back an html table of /proc/meminfo.  The bit in 
the test-server-http.c that instantiates it is like this, so you can see 
if you enabled cmake .. -DLWS_WITH_CGI=1  then you can got to /cgitest 
in the test server to see the script output.

		if (!strncmp(in, "/cgitest", 8)) {
			static char *cmd[] = {

			n = lws_cgi(wsi, cmd, 8 /* len of /cgitest */,
				    5 /* timeout secs */);

vfork + execvpe is only available on Linux + GNU stack.  Otherwise it 
falls back to fork + execvp.

At the moment the work is split between the user callback and the 
library for maxiumum flexibility, but it will likely turn out some of 
the user callback code can go in the library as the default callback action.

2) lws now has basic support for http rewriting proxying.  If you enable 
it with cmake .. -DLWS_WITH_HTTP_PROXY=1  then you will also need to 
have libhubbub on your box 
(http://www.netsurf-browser.org/projects/hubbub/) but this is already in 
the major distros.

It actually parses and regenerates the HTML using libhubbub operating in 
stream parser mode, replacing one selected string with another if it 
understands that the string is a legit URL.

This is enough for me to proxy http://git.libwebsockets.org through 
https in the test server, with the URIs rewritten to continue to work.

The end goal of these changes for me is to introduce a new "test server" 
lwsws, "libwebsockets webserver" which just does enough, as simply as 
possible, so I can run all my own web services on it instead of Apache.

Above all it should be sanely secure by default.

I don't think it should try to be like Apache, for that you can actually 
use Apache: instead it should just do all of what 90% of people need in 
as little space, with as few options and as little configuration as 

I'm particularly interested in simplifying out apache permissions and 
htaccess and such so they just work for normal cases using the main 
process permissions, cgi should just work and proxying should just work. 
  And because the backend is already in lws, lwsws should be very little 
code itself in addition.  If you have to add a vhost it should be so 
trivial you can just edit the JSON without docs.

Currently I'm imagining it takes JSON config file(s) from a ./conf.d/ 
something like this:


  "vhosts": [
   { "name": "warmcat.com",
     "host-ssl-key": "/etc/pki/tls/private/warmcat.com.key",
     "host-ssl-cert": "/etc/pki/tls/certs/warmcat.com.crt",
     "host-ssl-ca": "/etc/pki/tls/certs/warmcat.com.cer",
     "mounts": [
       { "/": [
        { "home": "file:///var/www/warmcat.com" },
        { "default": "index.html" }


  "vhosts": [
    { "name": "libwebsockets.org",
      "host-ssl-key":  "/etc/pki/tls/private/libwebsockets.org.key",
      "host-ssl-cert": "/etc/pki/tls/certs/libwebsockets.org.crt",
      "host-ssl-ca":   "/etc/pki/tls/certs/libwebsockets.org.cer",
      "mounts": [
        { "/": [
         { "home": "file:///var/www/libwebsockets.org" },
         { "default": "index.html" }
        { "/git": [
         { "home": "http://git.warmcat.com" },
         { "default": "/" }
        { "/mailman": [
         { "home": "cgi://usr/lib/mailman/cgi-bin/" },
         { "default": "/list-info" }

You can see it implies that we need changes to allow an SSL CTX per 
vhost... depending on what's wanted there might be more of these 
lws-level changes needed, so before starting on it, I'd like to hear any 
comments from interested potential users about what they'd have to see 
for it to work for them.


More information about the Libwebsockets mailing list