<div dir="ltr"><div class="gmail_extra">Everything works fine with lwsws top level function.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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 one using lws):</div><div class="gmail_extra">- Redirect certain http port to https port</div><div class="gmail_extra">- Use cgi (namely cgitest)</div><div class="gmail_extra">- mountpoint to different system folder (egg: server-status redirects to server-status/server-status.html)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I suppose that the above functions are not tied to lwsws but I managed to make it work neither with ./libwebsockets-test-server nor with ./libwebsockets-test-server-v2.0 (plugin activated)</div><div class="gmail_extra">All other functions are working (Dumb Increment Demo, Mirror demo, close testing, server info, post).</div><div class="gmail_extra"><br></div><div class="gmail_extra">By the way:</div><div class="gmail_extra">- is it possible (easily) to restrict access (ask for login/pwd) for some files/folders retrieved by HTTP like Apache do with .htpasswd?</div><div class="gmail_extra"><br></div><div class="gmail_extra">- I have seen "Lws platform-independent file access apis" but is it usable with any third party websocket client library? I suppose not...</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sorry for so many general questions.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra">Thomas</div><div class="gmail_extra">
<br><div class="gmail_quote">2016-05-17 16:05 GMT+02:00 Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<br>
On May 17, 2016 9:29:07 PM GMT+08:00, Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>> wrote:<br>
><br>
><br>
>On May 17, 2016 8:43:15 PM GMT+08:00, Thomas Spitz<br>
><<a href="mailto:thomas.spitz@hestia-france.com" target="_blank">thomas.spitz@hestia-france.com</a>> wrote:<br>
>>Everything work fine except cgitest (the test you explained here :<br>
>><a href="https://libwebsockets.org/pipermail/libwebsockets/2016-March/002253.html" rel="noreferrer" target="_blank">https://libwebsockets.org/pipermail/libwebsockets/2016-March/002253.html</a>)<br>
><br>
>Right, but I didn't put cgitest in the conf.d example.<br>
><br>
>If I understood it, you can reproduce the conf.d example as it is fine.<br>
<br>
</span>I added the test cgi script to the example localhost config at /testcgi.<br>
<br>
The test script issues headers to set the output to text/html and then sends a html table of /proc/meminfo.<br>
<br>
Managing spawned cgis has a quirk, to make it work reliably the server process is detached from the controlling terminal when spawning the cgi.  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 not, it means after running the cgi, ^C from the controlling tty won't reach lwsws.  It's not that lwsws ignores it, it's not attached to the terminal any more in a way that receives the signal.<br>
<br>
You can send it a SIGINT another way, like sudo killall -SIGINT lwsws and it will close fine.  But if you're planning on using cgi, you should run lwsws as a daemon.<br>
<br>
There's example systemd integration provided<br>
<br>
<a href="https://github.com/warmcat/libwebsockets/blob/master/lwsws/usr-lib-systemd-system-lwsws.service" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/master/lwsws/usr-lib-systemd-system-lwsws.service</a><br>
<span><font color="#888888"><br>
-Andy<br>
</font></span></blockquote></div><br></div></div>