<div dir="ltr">Oh, sid stands for session-id - I see.<div><br></div><div>I thought I'd changed the /usr/share to /usr/local/share - but as you worked out, I hadn't.</div><div><br></div><div>Now I've fixed that, I see an empty page. Looking at the source, I see style="display:none" on both the div elements. </div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 24 May 2016 at 17:11 Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 05/24/2016 11:52 PM, Colin Adams wrote:<br>
> OK. Getting nearer now.<br>
><br>
> If I understand the readme correctly, to get a login page i need to<br>
> point my browser to<br>
><br>
> <a href="http://localhost:7681/lwsgs" rel="noreferrer" target="_blank">http://localhost:7681/lwsgs</a><br>
><br>
> If I do that, I get a 404, and the log says:<br>
<br>
The canned paths in the readme assume things installed in /usr/share,<br>
you'll need to slip a '/local' in them if that's where they were installed.<br>
<br>
> lwsws[10660]: failed to get sid from wsi<br>
<br>
That's ok since no chance to paint the client with a cookie the first time.<br>
<br>
-Andy<br>
<br>
><br>
> On Tue, 24 May 2016 at 16:26 Colin Adams <<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a><br>
> <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>>> wrote:<br>
><br>
>     Confirmed that it acquired the apache id:<br>
><br>
>     ps -U root -u apache u | grep lwsws<br>
>     apache   10599  0.0  0.0  70032  6108 ?        Ss   16:25   0:00<br>
>     /usr/local/bin/lwsws -D<br>
><br>
><br>
>     On Tue, 24 May 2016 at 16:16 Colin Adams <<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a><br>
>     <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>>> wrote:<br>
><br>
>         I'm just calling<br>
>         sudo /usr/local/bin/lwsws<br>
>         so it ought to be running as root<br>
><br>
>         On Tue, 24 May 2016 at 16:13 Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a><br>
>         <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>> wrote:<br>
><br>
><br>
><br>
>             On May 24, 2016 11:10:32 PM GMT+08:00, Colin Adams<br>
>             <<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a> <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>>><br>
>             wrote:<br>
>              >OK. I've got it installed.<br>
>              ><br>
>              >But when running I get messages:<br>
>              ><br>
>              >lwsws[10192]: Unable to open session db<br>
>             /var/www/sessions/lws.sqlite3:<br>
>              >unable to open database file<br>
>              ><br>
>              >I don't know anything about sqlite3, but I'm guessing<br>
>             perhaps I need to<br>
>              >define a user name first? Or is there something missing<br>
>             from the readme<br>
>              >(I<br>
>              >issued the two commands to create the directory and set<br>
>             the owner to<br>
>              >root.apache).<br>
><br>
>             Are you starting it as root?  Otherwise it doesn't have the<br>
>             rights to change to run under apache uid.<br>
><br>
>             -Andy<br>
><br>
>              >On Tue, 24 May 2016 at 15:38 Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a><br>
>             <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>> wrote:<br>
>              ><br>
>              >><br>
>              >><br>
>              >> On 05/24/2016 09:06 PM, Colin Adams wrote:<br>
>              >> > I did:<br>
>              >> > git pull<br>
>              >> > cd build<br>
>              >> > make<br>
>              >> > sudo make install<br>
>              >> ><br>
>              >> > and got:<br>
>              >> > CMake Error at cmake_install.cmake:427 (file):<br>
>              >> > file INSTALL cannot find<br>
>              >"/home/colin/libwebsockets/plugins/lwsgs.js".<br>
>              >> ><br>
>              >> > I had previously done:<br>
>              >> ><br>
>              >> > cmake -D LWS_WITHOUT_DAEMONIZE=OFF -D LWS_WITH_PLUGINS=ON<br>
>              >> > -DLWS_WITH_LWSWS=1 ..<br>
>              >> ><br>
>              >> > so is there anything else I should have done?<br>
>              >><br>
>              >> No it's my fault, I missed it from git add.  Please<br>
>             fetch (not pull)<br>
>              >> master again.<br>
>              >><br>
>              >> Because master doesn't have a history, you need to track<br>
>             it like<br>
>              >this,<br>
>              >> assuming you have no local patches<br>
>              >><br>
>              >> $ git fetch <a href="https://github.com/warmcat/libwebsockets.git" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets.git</a><br>
>             +master:m &&<br>
>              >> git reset --hard m<br>
>              >><br>
>              >> -Andy<br>
>              >><br>
>              >> ><br>
>              >> > On Tue, 24 May 2016 at 11:26 Andy Green<br>
>             <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>><br>
>              >> > <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>>><br>
>             wrote:<br>
>              >> ><br>
>              >> ><br>
>              >> ><br>
>              >> >     On 05/24/2016 06:15 PM, Colin Adams wrote:<br>
>              >> >      > My opinion is that I personally will not need<br>
>             anything<br>
>              >beyond<br>
>              >> >     what you<br>
>              >> >      > have already described (but I am assuming that<br>
>             the email<br>
>              >address<br>
>              >> that<br>
>              >> >      > the user used for registration is available in<br>
>             the DB. And<br>
>              >maybe<br>
>              >> that<br>
>              >> >      > assumption is wrong).<br>
>              >> ><br>
>              >> >     It will be... you can see the schema here<br>
>              >> ><br>
>              >> ><br>
>              >><br>
>              ><a href="https://github.com/warmcat/libwebsockets/blob/master/plugins/protocol_generic_sessions.c#L522" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/master/plugins/protocol_generic_sessions.c#L522</a><br>
>              >> ><br>
>              >> >     but the register / email part is not wired up yet.<br>
>              >> ><br>
>              >> >     Currently I am imagining this "generic-sessions"<br>
>             plugin only<br>
>              >deals<br>
>              >> with<br>
>              >> >     authentication of a username.  That includes<br>
>             registration,<br>
>              >email<br>
>              >> >     confirmation, "forgot password", eventually admin<br>
>             maintenance<br>
>              >pages,<br>
>              >> >     managing the sesion database and so on, but NO other<br>
>              >information<br>
>              >> except<br>
>              >> >     the client has a cookie authenticated for a given<br>
>             username (or<br>
>              >no<br>
>              >> >     username if not logged in).<br>
>              >> ><br>
>              >> >     So the api to this in your ws protocol handler<br>
>             would only be<br>
>              >"what's<br>
>              >> my<br>
>              >> >     username".  If it gives you a username, you know<br>
>             it has been<br>
>              >> >     authenticated.  You can also segregate access to<br>
>             mounts by if<br>
>              >you're<br>
>              >> >     logged in, or logged in as admin, but that's it.<br>
>              >> ><br>
>              >> >     Storing stuff that your protocol handler deals in<br>
>             for that<br>
>              >user, eg,<br>
>              >> >     using the username as the db key, is completely a<br>
>             separate<br>
>              >issue<br>
>              >> private<br>
>              >> >     to your protocol handler.  It would, eg, use its<br>
>             own sqlite3<br>
>              >database<br>
>              >> >     for it if that's what he wanted to do.<br>
>              >> ><br>
>              >> >     -Andy<br>
>              >> ><br>
>              >> ><br>
>              >> >      > On Tue, 24 May 2016 at 11:11 Andy Green<br>
>             <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>><br>
>              >> >     <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>><br>
>              >> >      > <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a><br>
>             <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a><br>
>             <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>>>> wrote:<br>
>              >> >      ><br>
>              >> >      ><br>
>              >> >      ><br>
>              >> >      >     On 05/23/2016 11:37 PM, Andy Green wrote:<br>
>              >> >      >      ><br>
>              >> >      >      ><br>
>              >> >      >      > On May 23, 2016 9:14:57 PM GMT+08:00,<br>
>             Colin Adams<br>
>              >> >      >      > <<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a><br>
>             <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>><br>
>              >> >     <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a><br>
>             <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>>><br>
>              ><mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a><br>
>             <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>><br>
>              >> >     <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a><br>
>             <mailto:<a href="mailto:colinpauladams@gmail.com" target="_blank">colinpauladams@gmail.com</a>>>>> wrote:<br>
>              >> >      >      >> This sounds like something that I was<br>
>             going to have<br>
>              >to<br>
>              >> >     write myself<br>
>              >> >      >      >> for my application (a game server). I<br>
>             can't think<br>
>              >offhand<br>
>              >> >     of any<br>
>              >> >      >      >> further improvements, but I might find<br>
>             something<br>
>              >when I<br>
>              >> >     try it<br>
>              >> >      >      >> out. My C skills are 17 years rusty<br>
>             (apart from<br>
>              >fragments<br>
>              >> >     involved<br>
>              >> >      >      >> in writing language bindings), but I'm<br>
>             sure I can<br>
>              >polish<br>
>              >> >     them up if<br>
>              >> >      >      >> I find any enhancements needed. Is this<br>
>             in master<br>
>              >now?<br>
>              >> >      >      ><br>
>              >> >      >      > No, it's very much a WIP.<br>
>              >> >      >      ><br>
>              >> >      >      > But today it's working for admin login /<br>
>             logout, the<br>
>              >> cookies,<br>
>              >> >      >      > persistent session db, rewriting r/o<br>
>             copies of the<br>
>              >state<br>
>              >> >     into js vars<br>
>              >> >      >      > (so the example login page js can change<br>
>             to a logout<br>
>              >form<br>
>              >> >      >      > appropriately), and all customization in<br>
>             the lwsws<br>
>              >JSON<br>
>              >> >     and login<br>
>              >> >      >      > html (there are hidden form elements<br>
>             that control the<br>
>              >next<br>
>              >> url<br>
>              >> >      >      > depending on how the login / logout went).<br>
>              >> >      >      ><br>
>              >> >      >      > I'll tidy it up and add some docs<br>
>             tomorrow, and check<br>
>              >if<br>
>              >> >     it broke<br>
>              >> >      >      > anything else, but you can see it's only<br>
>             usable for<br>
>              >> >     development<br>
>              >> >      >      > today.<br>
>              >> >      ><br>
>              >> >      >     I pushed what there is of it... for now<br>
>             it's enabled in<br>
>              >cmake<br>
>              >> >     with<br>
>              >> >      >     LWS_WITH_LWSWS.<br>
>              >> >      ><br>
>              >> >      >     See<br>
>              >> >      ><br>
>              >> >      ><br>
>              >> ><br>
>              >><br>
>              ><a href="https://github.com/warmcat/libwebsockets/blob/master/README.generic-sessions.md" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/master/README.generic-sessions.md</a><br>
>              >> >      ><br>
>              >> >      >     You can add the mounts mentioned in there<br>
>             and the<br>
>              >protocol<br>
>              >> >     import part<br>
>              >> >      >     to the existing lwsws example config.<br>
>              >> >      ><br>
>              >> >      >     The admin account and password in the<br>
>             protocol config<br>
>              >part is<br>
>              >> >     admin /<br>
>              >> >      >     jipdocesExunt<br>
>              >> >      ><br>
>              >> >      >     If you navigate to<br>
>             <a href="http://localhost:7681/lwsgs" rel="noreferrer" target="_blank">http://localhost:7681/lwsgs</a> you<br>
>              >should see<br>
>              >> >     a login<br>
>              >> >      >     form that you can login with those<br>
>             credentials, which<br>
>              >will<br>
>              >> >     take you to a<br>
>              >> >      >     URL in /lwsgs/needadmin/... that cannot<br>
>             otherwise be<br>
>              >served.<br>
>              >> >      ><br>
>              >> >      >     If you go back and refresh the login page,<br>
>             it now knows<br>
>              >your<br>
>              >> >     session is<br>
>              >> >      >     authenticated and this time shows your<br>
>             login name<br>
>              >together<br>
>              >> >     with a logout<br>
>              >> >      >     button... this is done in JS clientside<br>
>             with the tiny<br>
>              >rewrite<br>
>              >> of<br>
>              >> >      >     "$lwsgs_user" in the included lwsgs.js.<br>
>              >> >      ><br>
>              >> >      >     The active sessions are stored in sqlite3<br>
>             on the server<br>
>              >side<br>
>              >> >     and the<br>
>              >> >      >     expiry, controlled from the config file,<br>
>             should be<br>
>              >respected.<br>
>              >> >      ><br>
>              >> >      >     The actual users will also go in a table in<br>
>             sqlite3, but<br>
>              >> admin's<br>
>              >> >      >     credentials are set in the config outside<br>
>             of that.<br>
>              >Those<br>
>              >> >     users and<br>
>              >> >      >     registration aren't done yet.<br>
>              >> >      ><br>
>              >> >      >      > I'm mainly wondering what people want<br>
>             from the<br>
>              >persistent<br>
>              >> >     user state,<br>
>              >> >      >      > in my case once authenticated, the next<br>
>             url is an<br>
>              >html<br>
>              >> >     page opening a<br>
>              >> >      >      > ws link that will also get the logged-in<br>
>             session<br>
>              >cookie.<br>
>              >> My<br>
>              >> >      >      > application is static html + js that<br>
>             dynamically<br>
>              >> >     configures itself<br>
>              >> >      >      > around the returned (user-context aware)<br>
>             JSON from<br>
>              >the ws<br>
>              >> >     link.<br>
>              >> >      >      ><br>
>              >> >      >      > Put another way the application's custom<br>
>             ws protocol<br>
>              >> >     handler code is<br>
>              >> >      >      > the guy who actually defines what<br>
>             different users<br>
>              >see...<br>
>              >> >     that pattern<br>
>              >> >      >      > removes the need for any other server-side<br>
>              >interpreter and<br>
>              >> >     just<br>
>              >> >      >      > manifests itself as delivering an<br>
>             authenticated<br>
>              >username<br>
>              >> >     into custom<br>
>              >> >      >      > ws protocol code you would have to write<br>
>             anyway.<br>
>              >Other<br>
>              >> >      >      > presentation-related code that needs to<br>
>             be aware of<br>
>              >> >     authentication<br>
>              >> >      >      > state (eg, show login form, or "logged<br>
>             in as xxx" +<br>
>              >logout<br>
>              >> >     button)<br>
>              >> >      >      > moves out of what would have been server<br>
>             scripts and<br>
>              >into<br>
>              >> >     js that got<br>
>              >> >      >      > some rewriting pixie dust.  But I am<br>
>             curious if that<br>
>              >> >     pattern is<br>
>              >> >      >      > enough to solve other peoples'<br>
>             session-related tasks,<br>
>              >> >     perhaps with a<br>
>              >> >      >      > little thought.<br>
>              >> >      ><br>
>              >> >      >     Still curious about opinions on this (maybe<br>
>             it's not<br>
>              >> >     explained clearly<br>
>              >> >      >     enough yet).<br>
>              >> >      ><br>
>              >> >      >     -Andy<br>
>              >> >      ><br>
>              >> >      >      > -Andy<br>
>              >> >      >      ><br>
>              >> >      >      >> On Mon, 23 May 2016 at 12:44 Andy Green<br>
>              ><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>><br>
>              >> >     <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>><br>
>              >> >      >     <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a><br>
>             <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a><br>
>             <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>>>><br>
>              >wrote:<br>
>              >> >      >      >><br>
>              >> >      >      >>> Hi -<br>
>              >> >      >      >>><br>
>              >> >      >      >>> I am partway through making a plugin<br>
>             called<br>
>              >> >     "generic-sessions",<br>
>              >> >      >      >> intended<br>
>              >> >      >      >>> to provide lightweight persistent http<br>
>             sessions<br>
>              >without a<br>
>              >> >      >      >>> server-side interpreter.<br>
>              >> >      >      >>><br>
>              >> >      >      >>> The overall ideas are:<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - random 20-byte session id managed in<br>
>             a cookie<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - all information related to the<br>
>             session held at<br>
>              >the<br>
>              >> server,<br>
>              >> >      >      >> nothing<br>
>              >> >      >      >>> managed clientside<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - sqlite3 used at the server to manage<br>
>             active<br>
>              >sessions<br>
>              >> >     and users<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - defaults to creating anonymous<br>
>             sessions with no<br>
>              >user<br>
>              >> >      >      >>> associated<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - admin account (with user-selectable<br>
>             username) is<br>
>              >> >     defined in<br>
>              >> >      >      >> config<br>
>              >> >      >      >>> with a SHA-1 of the password; rest of<br>
>             the accounts<br>
>              >are in<br>
>              >> >      >      >>> sqlite3<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - login, logout, register account + email<br>
>              >verification<br>
>              >> >     built-in<br>
>              >> >      >      >> with<br>
>              >> >      >      >>> examples<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - in a mount, some file suffixes (ie,<br>
>             .js) can be<br>
>              >> >     associated with<br>
>              >> >      >      >>> a protocol for the purposes of rewriting<br>
>              >symbolnames.<br>
>              >> >     These are<br>
>              >> >      >      >> read-only<br>
>              >> >      >      >>> copies of logged-in server state.<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - When your page fetches .js or other<br>
>             rewritten<br>
>              >files<br>
>              >> >     from that<br>
>              >> >      >      >> mount,<br>
>              >> >      >      >>> "$lwsgs_user" and so on are rewritten<br>
>             on the fly<br>
>              >using<br>
>              >> >     chunked<br>
>              >> >      >      >> transfer<br>
>              >> >      >      >>> encoding<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - Eliminates server-side scripting<br>
>             with a few<br>
>              >rewritten<br>
>              >> >     symbols<br>
>              >> >      >      >>> and javascript on client side<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - 32-bit bitfield for authentication<br>
>             sectoring,<br>
>              >mounts<br>
>              >> can<br>
>              >> >      >      >>> provide<br>
>              >> >      >      >> a<br>
>              >> >      >      >>> mask on the loggin-in session's associated<br>
>              >server-side<br>
>              >> >     bitfield<br>
>              >> >      >      >>> that must be set for access.<br>
>              >> >      >      >>><br>
>              >> >      >      >>> - No code (just config) required for,<br>
>             eg, private<br>
>              >URL<br>
>              >> >     namespace<br>
>              >> >      >      >> that<br>
>              >> >      >      >>> requires login to access.<br>
>              >> >      >      >>><br>
>              >> >      >      >>> Login, logout, cookies, rewriting are<br>
>             already done,<br>
>              >I am<br>
>              >> >     curious<br>
>              >> >      >      >> about<br>
>              >> >      >      >>> any comments or suggestions to make it<br>
>             more useful<br>
>              >> >     (especially<br>
>              >> >      >      >>> if<br>
>              >> >      >      >> anyone<br>
>              >> >      >      >>> is motivated to contribute).<br>
>              >> >      >      >>><br>
>              >> >      >      >>> -Andy<br>
>              >_______________________________________________<br>
>              >> >      >      >>> Libwebsockets mailing list<br>
>              >> > <a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>><br>
>              >> >     <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>>><br>
>              >> >      >     <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>><br>
>              >> >     <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>>>><br>
>              >> >      >      >>><br>
>              ><a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>              >> >      >      >>><br>
>              >> >      >      ><br>
>              >> >      >      ><br>
>             _______________________________________________<br>
>              >> >     Libwebsockets mailing<br>
>              >> >      >      > list <a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>><br>
>              >> >     <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>>><br>
>              >> >      >     <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>><br>
>              >> >     <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
>             <mailto:<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a>>>><br>
>              >> >      >      ><br>
>              ><a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>              >> >      >      ><br>
>              >> >      ><br>
>              >> ><br>
>              >><br>
><br>
</blockquote></div>