[Libwebsockets] CGI on lws

Andy Green andy at warmcat.com
Tue Feb 23 22:44:32 CET 2016



On February 24, 2016 12:00:24 AM GMT+08:00, James Stormes <jstormes at stormes.net> wrote:
>Andy,
>
>This is exactly what I am waiting for.  I work mostly in ASP C# and/or
>PHP
>and need to connect live data updates on the server to javascript.  My
>current best practice is long poll AJAX, but scalability is an issue.
>
>What I am looking for, and time permitting trying to build, is all the
>plumbing.  What you are doing can takes us a long way to connecting PHP
>on
>the server to JavaScript in the browser via web sockets.
>
>My suggestion is to build out enough to get connected to something like
>PHP
>and get some example code working so we can start finding issues in the
>design, and developing the techniques and best practice in the higher
>level
>languages.

Yes, he can already run arbitrary apps (eg, /bin/sh -c "cat /proc/meminfo") and send the output on http in the test server, with some example CGI env vars set.  I'll wire up POST to stdin and then start pushing it on master.  I guess there are still many things to get right, like timing out subprocesses, reaping children robustly, corner cases etc, so somebody testing it and/or sending patches is very welcome.

-Andy

>
>
>
>*James Stormes*
>*Software Developer*
>(817) 676-4291 (Cell)
>www.stormes.net
>
>Zend Certified Engineer
><http://www.zend.com/en/yellow-pages/ZEND026190>
>
>On Tue, Feb 23, 2016 at 5:06 AM, Andy Green <andy at warmcat.com> wrote:
>
>> Hi -
>>
>> I am working on adding a cmake-selectable CGI api to lws, basically
>>
>> LWS_VISIBLE LWS_EXTERN int
>> lws_cgi(struct lws *wsi, char * const *exec_array);
>>
>> LWS_VISIBLE LWS_EXTERN int
>> lws_cgi_kill(struct lws *wsi);
>>
>> where the forked process' stdin/out/err is piped on to three slave
>wsi
>> created in the same service thread as the master: these are managed
>through
>> the same event loop as everything else, when the process has output,
>his
>> pipe fd POLLIN fires and there's a user callback where the user code
>can
>> wire it up to outputting it when the sink socket is writeable.  That
>> happens piecemeal and multitasked according to the combination of
>server,
>> network and process conditions; the user code in the callback can
>choose to
>> wire it up to http[s] or ws[s] according to what they want.
>>
>> The guts of it work already in my local tree, but there are quite a
>lot of
>> things to take care about with regard to managing the event loop
>properly
>> for all cases, as well as deal with POST -> stdin and that might take
>a
>> while.
>>
>> The goal of it is to provide a primitive with which you can easily
>spawn
>> "io-encapsulated" subprocesses to the network, ie, run cgi like
>mailman or
>> general scripts or web language interpreters.
>>
>> I am curious if potential users of it have any comments or
>suggestions
>> about this direction, since it's one of decreasing number of missing
>bits
>> in the lws toolkit from the point of view of it being able to make a
>> generic webserver.
>>
>> -Andy
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at libwebsockets.org
>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>




More information about the Libwebsockets mailing list