[Libwebsockets] v2.0 coming very soon

Andy Green andy at warmcat.com
Tue Jun 14 07:28:27 CEST 2016



On 06/13/2016 10:49 PM, Thomas Spitz wrote:
> Thanks Andy,
>
> I forgot to change the shared libraries link and the env path for gdb
>
> It seems to work! I have to get deeper now, namely regarding file upload

I did some refactoring on the file upload api today (and a big 
refactoring on generic-sessions a couple of days ago), so make sure you 
use latest master and cut-and-paste the related code from there.  There 
are no functional changes just shorten api names.

I'm not expecting any more changes to the urldecode / multipart / upload 
stuff unless there are bugs.

The public test server is updated to use current master, so you can also 
try the test forms there

https://libwebsockets.org/testserver/

BTW current state of generic-sessions is also on that, you should be 
able to register, receive emails, verify your email, login, logout, and 
do forgot password email / verification (and also login as admin using 
admin / jipdocesExunt credentials).  But the test app doesn't do 
anything with it itself yet.

https://libwebsockets.org/lwsgs

-Andy

>
>
> 2016-06-13 15:45 GMT+02:00 Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>>:
>
>
>
>     On June 13, 2016 9:13:40 PM GMT+08:00, Thomas Spitz
>     <thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>> wrote:
>     >Hello again Andy,
>     >
>     >I have been trying to use lws core library and the following static
>     >mounts
>     >(test.html for static contents and protocol-post-demo for dynamic
>     >contents
>     >"HTTP requests"):
>     >
>     >> static const struct lws_http_mount mount_post = {
>     >> NULL, /* linked-list pointer to next*/
>     >> "/formtest", /* mountpoint in URL namespace on this vhost */
>     >> "protocol-post-demo", /* handler */
>     >> NULL, /* default filename if none given */
>     >> NULL,
>     >> NULL,
>     >> NULL,
>     >> NULL,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> LWSMPRO_CALLBACK, /* origin points to a callback */
>     >> 9, /* strlen("/formtest"), ie length of the mountpoint */
>     >> };
>     >> static const struct lws_http_mount mount_vHost = {
>     >> (struct lws_http_mount *)&mount_post, /* linked-list pointer to
>     >next*/
>     >> "/", /* mountpoint in URL namespace on this vhost */
>     >> LOCAL_RESOURCE_PATH, /* where to go on the filesystem for that */
>     >> "test.html", /* default filename if none given */
>     >> NULL,
>     >> NULL,
>     >> NULL,
>     >> NULL,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> 0,
>     >> LWSMPRO_FILE, /* mount type is a directory in a filesystem */
>     >> 1, /* strlen("/"), ie length of the mountpoint */
>     >> };
>     >
>     >As you suggested:
>     >
>     >> I have enclosed the complete test-server.c file. Main modifications
>     >are:
>     >>
>     >>>
>     >>>   * remove callback_http from protocols[]
>     >>> Hm... I think you still need a dummy protocols[0].
>     >>> How the plugins stuff works is you can give it no protocols[] at all
>     >>> (NULL in the info).  The context init stuff will point to to one
>     >dummy
>     >>> protocol callback, it basically does nothing but blows a 404 if
>     >anything
>     >>> reaches there.
>     >>>
>     >https://github.com/warmcat/libwebsockets/blob/master/lib/context.c#L181
>     >>
>     >> I added a HTTP dummy protocol (callback_http_dummy) but my mounts are
>     >never served. When requesting http://localhost:7681/ I always get 404
>     >error
>     >page.
>     >
>     >> Mounts however seem OK for lws:
>     >> lwsts[20663]: Initial logging level 7
>     >> lwsts[20663]: Libwebsockets version: 2.0.0 thomas at thomas-laptop-
>
>     Is this library current master?
>
>     >> lwsts[20663]: IPV6 not compiled in
>     >> lwsts[20663]: libev support not compiled in
>     >> lwsts[20663]: libuv support compiled in but disabled
>     >> lwsts[20663]:  Threads: 1 each 4096 fds
>     >> lwsts[20663]:  mem: platform fd map: 32768 bytes
>     >> lwsts[20663]:  Compiled with OpenSSL support
>     >> lwsts[20663]:  SSL disabled: no LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT
>     >> lwsts[20663]: Creating Vhost 'default' port 7681, 2 protocols
>     >> lwsts[20663]:    mounting
>     >http:///home/thomas/workspace/test-libwebsockets-master-PC/serveurweb
>     >> to /
>     >> lwsts[20663]:    mounting http://protocol-post-demo to /formtest
>
>     No... these should be file:/// ... so something is broken.
>
>     Looking at your code the struct definitions match current master and
>     use LWSMPRO_FILE correctly.  Is the libwebsockets.so it binds to
>     actually the right version (also current master)?
>
>     >> lwsts[20663]:  Listening on port 7681
>     >> lwsts[20663]:  mem: per-conn:          648 bytes + protocol rx buf
>     >> lwsts[20663]:  canonical_hostname = thomas-laptop
>     >> lwsts[20663]: lws_protocol_init
>     >
>     >I even tried to add a Per-Vhost Options linked list :
>     >
>     >> static const struct lws_protocol_vhost_options pvo_opt = {
>     >> NULL,
>     >> NULL,
>     >> "default",
>     >> "1"
>     >> };
>     >> static const struct lws_protocol_vhost_options pvo = {
>     >> NULL,
>     >> &pvo_opt,
>     >> "protocol-post-demo",
>     >> ""/* ignored, just matches the protocol name above */
>     >> };
>     >
>     >but I suppose it doesn't have any effect as I am not using plugins at
>     >all.
>
>     ...
>     Plugins are just a way to deliver reusable protocols and callbacks
>     to your app without changing any code.  They don't have ANY bearing
>     on any other lws function.... EVERYTHING else works with the
>     protocol the same, whether it came in from a plugin or not.  In fact
>     after it collected the plugins at init time, nothing knows or cares
>     where a particular protocol came from.
>
>     Pvo works... mounts work... cgi works... JSON conf works...
>     EVERYTHING works the same, either way.
>
>     -Andy
>
>     >Thanks for your great help.
>     >Best regards,
>     >Thomas
>     >PS: I enclosed my demo project.
>     >
>     >2016-06-06 11:15 GMT+02:00 Andy Green <andy at warmcat.com
>     <mailto:andy at warmcat.com>>:
>     >
>     >>
>     >>
>     >> On 06/06/2016 05:07 PM, Thomas Spitz wrote:
>     >>
>     >>> Hello Andy,
>     >>>
>     >>> When you answered :
>     >>>
>     >>>     >So I wanted to use vhost LWSMPRO_CALLBACK functionnality but
>     >>> apparently
>     >>>     >it
>     >>>     >is bind to plugin approach... So bad for me ;-)
>     >>>     No it is not bound to plugins.  It just uses the protocol array,
>     >it
>     >>>     doesn't care if that array was provided directly by user code or
>     >>>     synthesized by collecting the protocols from different plugins
>     >at
>     >>>     init time... after init, the two situations are the same.  The
>     >>>     protocols are referred to using their name and looked up in the
>     >>>     protocols array, nobody cares at that point where the protocols
>     >>>     array came from.
>     >>>
>     >>> I understand that a protocol array  provided directly by user code
>     >or
>     >>> synthesized by collecting the protocols from different plugins at
>     >init
>     >>> time is the same. In my case, I wanted the protocol-post-demo code
>     >to
>     >>> come from a C function from my C project and not from a C file
>     >compiled
>     >>> externally and placed in a plugin dir.
>     >>>
>     >>
>     >> Well, okay.
>     >>
>     >> In other word, I wanted to specify a C function instead of a name in
>     >the
>     >>>
>     >>
>     >> ...
>     >>
>     >> below handler:
>     >>>
>     >>>     static const struct lws_http_mount mount_post = {
>     >>>     NULL,/* linked-list pointer to next*/
>     >>>     "/formtest",/* mountpoint in URL namespace on this vhost */
>     >>>     "protocol-post-demo",/* handler */
>     >>>     NULL,/* default filename if none given */
>     >>>     NULL,
>     >>>     NULL,
>     >>>     0,
>     >>>     0,
>     >>>     0,
>     >>>     0,
>     >>>     0,
>     >>>     LWSMPRO_CALLBACK,/* origin points to a callback */
>     >>>     9/* strlen("/formtest"), ie length of the mountpoint */
>     >>>     };
>     >>>
>     >>>
>     >>> but I think it is not possible..
>     >>>
>     >>
>     >> Every protocol definition lets you define a callback function and a
>     >name.
>     >> So being able to give the protocol name in the mount is actually the
>     >same
>     >> as being able to identify the callback function you want calling.
>     >>
>     >> You just need to define one of your protocols[] array (that you are
>     >giving
>     >> directly in your code, since you are trying to avoid plugins) to have
>     >the
>     >> callback that you want get called.  Give that protocol the name
>     >> "protocol-post-demo" (or change the name in both the protocol[] and
>     >the
>     >> mount) and you are done.
>     >>
>     >> -Andy
>     >>
>     >> Best regards,
>     >>> Thomas
>     >>>
>     >>>
>     >>> 2016-06-02 23:58 GMT+02:00 Andy Green <andy at warmcat.com
>     <mailto:andy at warmcat.com>
>     >>> <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>:
>     >>>
>     >>>
>     >>>
>     >>>     On June 3, 2016 12:21:08 AM GMT+08:00, Thomas Spitz
>     >>>     <thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>> wrote:
>     >>>     >Hello Andy,
>     >>>     >>
>     >>>     >>
>     >>>     >> In fact, as for an example, I modified test-server in order
>     >not to
>     >>>     >have
>     >>>     >>> to write my own callback_http but still have post_demo
>     >example
>     >>>     >working.
>     >>>     >>
>     >>>     >> test-server-v2.0.c already does this, using plugins.
>     >>>     >
>     >>>     >
>     >>>     >>
>     >>>     >As I already mentionned in our previous discussions, I
>     >unfortunately
>     >>>     >cannot
>     >>>     >use plugins because it implies too much refactoring of my
>     >project.
>     >>>
>     >>>     Well, you know your code.  But there is a tradeoff there in
>     >terms of
>     >>>     difficulty you're creating on lws side as I already noted.
>     >>>
>     >>>     >So I wanted to use vhost LWSMPRO_CALLBACK functionnality but
>     >>> apparently
>     >>>     >it
>     >>>     >is bind to plugin approach... So bad for me ;-)
>     >>>
>     >>>     No it is not bound to plugins.  It just uses the protocol array,
>     >it
>     >>>     doesn't care if that array was provided directly by user code or
>     >>>     synthesized by collecting the protocols from different plugins
>     >at
>     >>>     init time... after init, the two situations are the same.  The
>     >>>     protocols are referred to using their name and looked up in the
>     >>>     protocols array, nobody cares at that point where the protocols
>     >>>     array came from.
>     >>>
>     >>>     >I will therefore definitively keep on giving HTTP support in
>     >the "low
>     >>>     >level" code manner (based on callback_http of
>     >>>     >test-server/test-server-http.c)
>     >>>
>     >>>     Mounts work fine without plugins too.
>     >>>
>     >>>     Plugins don't go any deeper into lws than providing an
>     >alternative
>     >>>     way to supply protocol callback code, and to assemble an
>     >oldstyle
>     >>>     protocols[] array dynamically onetime at init.  That much has
>     >big
>     >>>     benefits architecturally, since interesting protocols can now be
>     >>>     reused cleanly and mix-and-matched per-vhost casually.
>     >>>
>     >>>     Your valgrind problem is something to do with a vsprintf
>     >touching
>     >>>     something it shouldn't, ie, a log argument or sprintf argument.
>     >If
>     >>>     you rebuild in DEBUG as suggested, valgrind should report the
>     >>>     related line number and it shouldn't be hard to get a grip on
>     >>>     whatever that is.  It's probably something small rather than a
>     >>>     gateway to hell.
>     >>>
>     >>>     >By the way, is there a way (without plugin support) to accept
>     >both
>     >>> HTTP
>     >>>     >and
>     >>>     >HTTPs but only WSS? The idea is to provide a webpage that can
>     >be
>     >>>     >reached
>     >>>     >either in HTTP (port 80) or HTTPs (port 443) but then only
>     >accept WSS
>     >>>     >(not
>     >>>     >WS without SSL) because my authentification is done through
>     >WSS.
>     >>>
>     >>>     Make a vhost on :443 and put your mounts and everything there.
>     >Then
>     >>>     add a second vhost on :80 that redirects to https://myhost (ie,
>     >on
>     >>> 443).
>     >>>
>     >>>     I can feel you're about to reply, 'ah! but it's not exactly what
>     >I
>     >>>     asked!' however what you asked is insecure since there is no way
>     >for
>     >>>     the browser to validate your host on port 80.  If someone is on
>     >an
>     >>>     AP controlled by the attacker, eg, "Free Airport Wifi", he can
>     >MITM
>     >>>     the port 80 access and add things to the non-https page that
>     >lets
>     >>>     him use the authenticated wss connection.
>     >>>
>     >>>     The only way to do that securely is bounce him to 443 from the
>     >>>     start, and give him the STS header so subsequently his browser
>     >knows
>     >>>     to directly go to 443 even if he typed http.  You can request
>     >the
>     >>>     STS is sent by adding info.options |= LWS_SERVER_OPTION_STS;
>     >when
>     >>>     creating the vhost for 443.  (or if using lwsws conf, just this
>     >in
>     >>>     the vhost definition
>     >>>
>     >>>          "sts": "on",
>     >>>
>     >>>     )
>     >>>
>     >>>     If you're unmoved by that, then, well, just repeat the vhost
>     >>>     contents, including the mounts in both :443 and :80 vhosts, and
>     >in
>     >>>     both cases have the JS open wss://.... but not a good idea
>     >>>     security-wise.
>     >>>
>     >>>     -Andy
>     >>>
>     >>>     >
>     >>>     >Best regadrs,
>     >>>     >Thomas
>     >>>     >
>     >>>     >2016-06-02 12:46 GMT+02:00 Andy Green <andy at warmcat.com
>     <mailto:andy at warmcat.com>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>:
>     >>>     >
>     >>>     >>
>     >>>     >>
>     >>>     >> On 06/02/2016 06:11 PM, Thomas Spitz wrote:
>     >>>     >>
>     >>>     >>> Hello Andy,
>     >>>     >>>
>     >>>     >>> In my previous email, I asked you about LWSMPRO_CALLBACKin
>     >stable
>     >>>     >release.
>     >>>     >>>
>     >>>     >>
>     >>>     >> It only exists on master, where I have the freedom to change
>     >>> related
>     >>>     >> things, by design.
>     >>>     >>
>     >>>     >> In fact, as for an example, I modified test-server in order
>     >not to
>     >>>     >have
>     >>>     >>> to write my own callback_http but still have post_demo
>     >example
>     >>>     >working.
>     >>>     >>>
>     >>>     >>
>     >>>     >> test-server-v2.0.c already does this, using plugins.
>     >>>     >>
>     >>>     >> I have enclosed the complete test-server.c file. Main
>     >modifications
>     >>>     >are:
>     >>>     >>>
>     >>>     >>>   * remove callback_http from protocols[]
>     >>>     >>>
>     >>>     >>
>     >>>     >> Hm... I think you still need a dummy protocols[0].
>     >>>     >>
>     >>>     >> How the plugins stuff works is you can give it no protocols[]
>     >at
>     >>> all
>     >>>     >(NULL
>     >>>     >> in the info).  The context init stuff will point to to one
>     >dummy
>     >>>     >protocol
>     >>>     >> callback, it basically does nothing but blows a 404 if
>     >anything
>     >>>     >reaches
>     >>>     >> there.
>     >>>     >>
>     >>>     >>
>     >>>     >
>     >>>
>     >https://github.com/warmcat/libwebsockets/blob/master/lib/context.c#L181
>     >>>     >>
>     >>>     >> He also provides default routing for CGI stdin/out/err if CGI
>     >is
>     >>>     >> configured.
>     >>>     >>
>     >>>     >> When the plugins are discovered, the vhost list of protocols
>     >is
>     >>>     >matched
>     >>>     >> against the existing protocols from the plugins, and a new
>     >>> per-vhost
>     >>>     >> generated protocols[] array is created starting with a copy
>     >of the
>     >>>     >dummy
>     >>>     >> protocol[0] and followed by the ones the vhost listed as
>     >allowed
>     >>> for
>     >>>     >him.
>     >>>     >>
>     >>>     >> So with plugins, there is still always a protocols[0] for
>     >http,
>     >>> even
>     >>>     >if
>     >>>     >> you initialized it to have no protocols in your user code.
>     >>>     >>
>     >>>     >>   * copy paste callback_post_demo from
>     >plugin/protocol_post_demo
>     >>>     >>>   * Add a linked list of 2 mounts for "test.html" and
>     >>>     >"protocol-post-demo"
>     >>>     >>>
>     >>>     >>> Everything works fine except that form-test only works once
>     >(I get
>     >>>     >the
>     >>>     >>> Form results in the browser) before server crashes
>     >>>     >>>
>     >>>     >>
>     >>>     >> If you use the test-server-v2.0.c directly and the provided
>     >>> plugins,
>     >>>     >to
>     >>>     >> test POST, is there any problem?  I am guessing not, since
>     >>> otherwise
>     >>>     >> libwebsockets.org <http://libwebsockets.org>
>     <http://libwebsockets.org>, which offers
>     >>>     plugin-based POST would have blown up
>     >>>     >> long ago.
>     >>>     >>
>     >>>     >> To help debug your problem, make sure you configure lws and
>     >your
>     >>> app
>     >>>     >to
>     >>>     >> build with debug info... for lws it's
>     >>>     >>
>     >>>     >> $ cmake .. -DCMAKE_BUILD_TYPE=DEBUG
>     >>>     >>
>     >>>     >> That way you might get some line numbers in your backtrace,
>     >which
>     >>>     >will
>     >>>     >> obviously make finding the bug a lot easier.
>     >>>     >>
>     >>>     >> -Andy
>     >>>     >>
>     >>>     >> Here the trace of the test-server:
>     >>>     >>>
>     >>>     >>>     thomas at thomas-laptop
>     >>>     >>>
>     >>>
>     >>>
>     >>:~/workspace/Varuna4/0_librairies_sources/libwebsockets/buildPC-nolwsws-noplugins/bin$
>     >>>     >>>     ./libwebsockets-test-server
>     >>>     >>>     lwsts[25448]: libwebsockets test server - license
>     >LGPL2.1+SLE
>     >>>     >>>     lwsts[25448]: (C) Copyright 2010-2016 Andy Green
>     >>>     ><andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>
>     >>>     >>>     Using resource path "./share/libwebsockets-test-server"
>     >>>     >>>     lwsts[25448]: Initial logging level 7
>     >>>     >>>     lwsts[25448]: Libwebsockets version: 2.0.0
>     >>> thomas at thomas-laptop-
>     >>>     >>>     lwsts[25448]: IPV6 not compiled in
>     >>>     >>>     lwsts[25448]: libev support not compiled in
>     >>>     >>>     lwsts[25448]: libuv support not compiled in
>     >>>     >>>     lwsts[25448]:  Threads: 1 each 1024 fds
>     >>>     >>>     lwsts[25448]:  mem: platform fd map:  8192 bytes
>     >>>     >>>     lwsts[25448]:  Compiled with OpenSSL support
>     >>>     >>>     lwsts[25448]:  SSL disabled: no
>     >>>     >LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT
>     >>>     >>>     lwsts[25448]: Creating Vhost 'default' port 7681, 5
>     >protocols
>     >>>     >>>     lwsts[25448]:    mounting
>     >>>     >file://./share/libwebsockets-test-server to
>     >>>     >>> /
>     >>>     >>>     lwsts[25448]:    mounting callback://protocol-post-demo
>     >to
>     >>>     >/formtest
>     >>>     >>>     lwsts[25448]:  Listening on port 7681
>     >>>     >>>     lwsts[25448]:  mem: per-conn:          480 bytes +
>     >protocol rx
>     >>>     >buf
>     >>>     >>>     lwsts[25448]:  canonical_hostname = thomas-laptop
>     >>>     >>>     lwsts[25448]: lws_protocol_init
>     >>>     >>>     lwsts[25448]: test_server_fops_open: opening
>     >>>     >>>     ./share/libwebsockets-test-server/test.html, ret 9, len
>     >18530
>     >>>     >>>     lwsts[25448]: test_server_fops_open: opening
>     >>>     >>>
>     >./share/libwebsockets-test-server/libwebsockets.org-logo.png,
>     >>>     >ret 9,
>     >>>     >>>     len 7029
>     >>>     >>>         get  = /xxx
>     >>>     >>>         host: = 192.168.1.190:7681
>     <http://192.168.1.190:7681>
>     ><http://192.168.1.190:7681>
>     >>>     <http://192.168.1.190:7681>
>     >>>     >>>
>     >>>     >>>         connection: = Upgrade
>     >>>     >>>         upgrade: = websocket
>     >>>     >>>         origin: = http://192.168.1.190:7681
>     >>>     >>>         sec-websocket-extensions: = permessage-deflate;
>     >>>     >>>     client_max_window_bits
>     >>>     >>>         sec-websocket-protocol: = dumb-increment-protocol
>     >>>     >>>         http/1.1  = HTTP/1.1
>     >>>     >>>         accept-encoding: = gzip, deflate, sdch
>     >>>     >>>         accept-language: =
>     >fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
>     >>>     >>>         pragma: = no-cache
>     >>>     >>>         cache-control: = no-cache
>     >>>     >>>         sec-websocket-key: = vO6t+VKg0zBTZkrsCja3kA==
>     >>>     >>>         sec-websocket-version: = 13
>     >>>     >>>         user-agent: = Mozilla/5.0 (Windows NT 10.0; WOW64)
>     >>>     >>>     AppleWebKit/537.36 (KHTML, like Gecko)
>     >Chrome/51.0.2704.63
>     >>>     >>> Safari/537.36
>     >>>     >>>     lwsts[25448]:  permessage-deflate requires the protocol
>     >>>     >>>     (dumb-increment-protocol) to have an RX buffer >= 128
>     >>>     >>>     lwsts[25448]: ext permessage-deflate failed construction
>     >>>     >>>     lwsts[25448]:  Capping pmd rx to 128
>     >>>     >>>     lwsts[25448]: cache_len 280
>     >>>     >>>     lwsts[25448]: lws_header_table_detach: wsi 0x1faee50: ah
>     >held
>     >>>     >6s,
>     >>>     >>>     ah.rxpos 559, ah.rxlen 559, mode/state 5
>     >>> 5,wsi->more_rx_waiting
>     >>>     >0
>     >>>     >>>     lwsts[25448]: test_server_fops_open: opening
>     >>>     >>>     ./share/libwebsockets-test-server/favicon.ico, ret 11,
>     >len
>     >>> 1406
>     >>>     >>>         get  = /xxx
>     >>>     >>>         host: = 192.168.1.190:7681
>     <http://192.168.1.190:7681>
>     ><http://192.168.1.190:7681>
>     >>>     <http://192.168.1.190:7681>
>     >>>     >>>         connection: = Upgrade
>     >>>     >>>         upgrade: = websocket
>     >>>     >>>         origin: = http://192.168.1.190:7681
>     >>>     >>>         sec-websocket-extensions: = permessage-deflate;
>     >>>     >>>     client_max_window_bits
>     >>>     >>>         sec-websocket-protocol: = lws-mirror-protocol
>     >>>     >>>         http/1.1  = HTTP/1.1
>     >>>     >>>         accept-encoding: = gzip, deflate, sdch
>     >>>     >>>         accept-language: =
>     >fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
>     >>>     >>>         pragma: = no-cache
>     >>>     >>>         cache-control: = no-cache
>     >>>     >>>         sec-websocket-key: = sU8nB7+0wS9MMJse8B3cIw==
>     >>>     >>>         sec-websocket-version: = 13
>     >>>     >>>         user-agent: = Mozilla/5.0 (Windows NT 10.0; WOW64)
>     >>>     >>>     AppleWebKit/537.36 (KHTML, like Gecko)
>     >Chrome/51.0.2704.63
>     >>>     >>> Safari/537.36
>     >>>     >>>     lwsts[25448]:  Capping pmd rx to 128
>     >>>     >>>     *** Error in `./libwebsockets-test-server': malloc():
>     >memory
>     >>>     >>>     corruption: 0x000000000200b0d0 ***
>     >>>     >>>     Aborted (core dumped)
>     >>>     >>>
>     >>>     >>> Any idea?
>     >>>     >>>
>     >>>     >>> Thanks in advance
>     >>>     >>> Best regards,
>     >>>     >>> Thomas
>     >>>     >>>
>     >>>     >>>
>     >>>     >>> 2016-06-02 10:49 GMT+02:00 Thomas Spitz
>     >>>     ><thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com> <mailto:
>     >>> thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>
>     >>>     >>> <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>>>:
>     >>>     >>>
>     >>>     >>>     Hello Andy,
>     >>>     >>>
>     >>>     >>>     I have seen that you released v2.0.2 (on
>     >>>     >>>     https://libwebsockets.org/git/libwebsockets/) but I am
>     >>> surprised
>     >>>     >>>     there is no LWSMPRO_CALLBACK in /lib/libwebsockets.h
>     >given
>     >>> that
>     >>>     >you
>     >>>     >>>     mention it
>     >>>     >>>     in
>     >>>     >>>
>     >>>     >
>     >>>
>     >https://github.com/warmcat/libwebsockets/blob/master/README.coding.md
>     >>>     >>>
>     >>>     >>>     Best regards,
>     >>>     >>>     Thomas Spitz
>     >>>     >>>
>     >>>     >>>
>     >>>     >>>     2016-05-26 22:31 GMT+02:00 Andy Green
>     <andy at warmcat.com <mailto:andy at warmcat.com>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>:
>     >>>     >>>
>     >>>     >>>
>     >>>     >>>
>     >>>     >>>         On May 26, 2016 11:19:05 PM GMT+08:00, Thomas Spitz
>     >>>     >>>         <thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>
>     >>>     >>>         <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>>> wrote:
>     >>>     >>>         >>
>     >>>     >>>         >>     Maybe you should better prototype it with the
>     >high
>     >>>     >end
>     >>>     >>> stuff and
>     >>>     >>>         >>
>     >>>     >>>         >>     when it works, look at reducing that to code,
>     >>>     >including the
>     >>>     >>>         >plugin
>     >>>     >>>         >>     content direct in your app etc if you still
>     >want
>     >>> to.
>     >>>     >>>         >> This is what I have done. First lwsws, then
>     >>>     >test-server-v2.0
>     >>>     >>> then
>     >>>     >>>         >> test-server then my program
>     >>>     >>>         >> This leads me to use lws in the old manner
>     >because my
>     >>>     >main ws
>     >>>     >>>         >protocol
>     >>>     >>>         >> (which is part of my program) cannot be launched
>     >as
>     >>>     >plugin
>     >>>     >>> (too much
>     >>>     >>>         >> work to make it work as separate program and also
>     >too
>     >>>     >hard to
>     >>>     >>> debug
>     >>>     >>>         >then)
>     >>>     >>>         >> I don't really understand your situation, but it
>     >is
>     >>> not a
>     >>>     >>> separate
>     >>>     >>>         >> program.  As I mentioned the one plugin can
>     >service
>     >>> both
>     >>>     >ws
>     >>>     >>> and http
>     >>>     >>>         >in the
>     >>>     >>>         >> one callback function.  Maybe I misunderstand.
>     >>>     >>>         >>
>     >>>     >>>         >> My problem might be sum up to the following : I
>     >cannot
>     >>>     >easily
>     >>>     >>>         >separate
>     >>>     >>>         >test-server program into 2 programs compiled
>     >separately
>     >>>     >>>         >(test-server-v2.0
>     >>>     >>>         >on one side and protocol_my_protocol on other
>     >side). In
>     >>>     >fact my
>     >>>     >>> program
>     >>>     >>>         >share data with each client (mutex, * client_wsi,
>     >>>     >program_data,
>     >>>     >>>         >client_data, client pthread, ...) AND my program is
>     >also
>     >>>     >able to
>     >>>     >>>         >start/stop
>     >>>     >>>         >the server (run into a thread) in order to
>     >reconfigure
>     >>> it.
>     >>>     >I'm
>     >>>     >>>
>     >>>     >>>         I dunno if this is the point, but in the info struct
>     >there
>     >>>     >is this
>     >>>     >>>
>     >>>     >>>          * @user:       CONTEXT: optional user pointer that
>     >can be
>     >>>     >>>         recovered via the context
>     >>>     >>>          *              pointer using lws_context_user
>     >>>     >>>
>     >>>     >>>         So you can pass in here a pointer to your shared
>     >data
>     >>> struct
>     >>>     >>>         between the main app and lws service thread.
>     >Everywhere
>     >>> in
>     >>>     >your
>     >>>     >>>         code that has access to lws_context, eg, every
>     >protocol
>     >>>     >plugin
>     >>>     >>>         callback, has access to that struct; you can share
>     >the
>     >>>     >struct
>     >>>     >>>         declaration by #include the same header in the
>     >plugin as
>     >>> the
>     >>>     >>>         main app.
>     >>>     >>>
>     >>>     >>>         That means eg a protocol plugin running in its
>     >service
>     >>>     >thread
>     >>>     >>>         can directly share and change any data with the main
>     >app's
>     >>>     >thread.
>     >>>     >>>
>     >>>     >>>         Although a plugin
>     >>>     >>>
>     >>>     >>>          - has its code separated
>     >>>     >>>
>     >>>     >>>          - may be built separately from the main app
>     >>>     >>>
>     >>>     >>>         It is NOT a separate thread or process or has
>     >private
>     >>>     >virtual
>     >>>     >>>         memory restriction like it was fork()ed.  When the
>     >plugin
>     >>> is
>     >>>     >>>         loaded, it becomes part of the process using lws,
>     >almost
>     >>>     >exactly
>     >>>     >>>         like it was all compiled together originally.
>     >>>     >>>
>     >>>     >>>         It doesn't have access to main app global vars
>     >directly,
>     >>>     >that's
>     >>>     >>>         true, but if you put the related globals in a
>     >(global)
>     >>>     >struct
>     >>>     >>>         and set info.user to point to it when you create the
>     >>>     >context,
>     >>>     >>>         all plugins can have access to it easily giving the
>     >same
>     >>>     >result.
>     >>>     >>>
>     >>>     >>>         My guess is every objection to plugins has a similar
>     >>>     >solution,
>     >>>     >>>         although maybe some of your problems need new apis
>     >once I
>     >>>     >>>         understand them.
>     >>>     >>>
>     >>>     >>>         >I will unfortunately have to implement low-level
>     >code for
>     >>>     >static
>     >>>     >>> (GET
>     >>>     >>>         >>
>     >>>     >>>         >> file like leaf.png with/without authentification)
>     >and
>     >>>     >dynamic
>     >>>     >>> (HTTP
>     >>>     >>>         >> GET/POST command) HTTP serving.
>     >>>     >>>         >> Can you tell a little more about why you "have"
>     >to do
>     >>> the
>     >>>     >low
>     >>>     >>> level
>     >>>     >>>         >> serving code for static files?
>     >>>     >>>         >>
>     >>>     >>>         >> -> some files have to be retrieved from other
>     >locations
>     >>>     >than
>     >>>     >>> where
>     >>>     >>>         >"test.html" is (for instance from a given folder in
>     >a SD
>     >>>     >card)
>     >>>     >>>         >
>     >>>     >>>         >> If it's auth, the generic-sessions plugin is
>     >aimed at
>     >>>     >>> providing that.
>     >>>     >>>         >
>     >>>     >>>         >In order not to enable anybody retrieve those files
>     >on SD
>     >>>     >card,
>     >>>     >>> I need
>     >>>     >>>         >to
>     >>>     >>>         >protect them by login/password (In fact the only
>     >users
>     >>>     >enabled
>     >>>     >>> are the
>     >>>     >>>         >user
>     >>>     >>>         >that manage to connect through our ws protocol
>     >using our
>     >>>     >own auth
>     >>>     >>>         >policy).
>     >>>     >>>         >I could have used your future generic-sessions
>     >plugin
>     >>>     >(except I
>     >>>     >>> am
>     >>>     >>>         >afraid
>     >>>     >>>         >sqlite is redundant with my actual 400 users
>     >login/pwd
>     >>>     >struct)
>     >>>     >>> but as I
>     >>>     >>>         >cannot use plugins due to separate compilation and
>     >shared
>     >>>     >>> compenents..
>     >>>     >>>
>     >>>     >>>         400 users sounds to me like you really need sqlite
>     >>> actually.
>     >>>     >>>
>     >>>     >>>         If you look into that I think you will end up with
>     >>> needing a
>     >>>     >>>         "session".  Then the amount of duplicated work will
>     >be
>     >>> very
>     >>>     >big.
>     >>>     >>>
>     >>>     >>>         sqlite also has a handy feature you can do sql from
>     >the
>     >>>     >>>         commandline on the db, eg to init your 400 users if
>     >you
>     >>>     >won't
>     >>>     >>>         let them create their own accounts over the web ui.
>     >>>     >>>
>     >>>     >>>         >I agree you'll have to do your own dynamic HTTP
>     >serving
>     >>>     >code,
>     >>>     >>> but this
>     >>>     >>>         >can
>     >>>     >>>         >> coexist in the same plugin - the same source file
>     >- as
>     >>>     >the ws
>     >>>     >>> serving
>     >>>     >>>         >part,
>     >>>     >>>         >> if that helps.
>     >>>     >>>         >
>     >>>     >>>         >Without plugins, I think of serving dynamic HTTP
>     >using
>     >>>     >general
>     >>>     >>>         >callback_http
>     >>>     >>>
>     >>>     >>>         Yes, for the dynamic html, you are into that one way
>     >or
>     >>>     >another.
>     >>>     >>>
>     >>>     >>>         But architecturally, you should be able to do it
>     >from a
>     >>>     >plugin.
>     >>>     >>>
>     >>>     >>>         >Hope you will keep test-server always up to date
>     >>>     >>>         >>
>     >>>     >>>         >>
>     >>>     >>>         >> One minor question : Is it possible to do port
>     >>>     >redirection with
>     >>>     >>>         >> test-server (http 80 -> redirect to https 7681).
>     >By the
>     >>>     >way one
>     >>>     >>>         >drawback
>     >>>     >>>         >> Sure... you make a vhost at the port you want to
>     >>>     >redirect,
>     >>>     >>>         and tell
>     >>>     >>>         >it the
>     >>>     >>>         >> new URL in the origin  (This one redirects SSL on
>     >port
>     >>>     >7681,
>     >>>     >>>         where I
>     >>>     >>>         >used
>     >>>     >>>         >> to run the test server, to SSL on port 443 and
>     >the URL
>     >>>     >where
>     >>>     >>>         it now
>     >>>     >>>         >lives)
>     >>>     >>>         >>     {
>     >>>     >>>         >>         # the old test server ran this on :7681,
>     >put a
>     >>>     >redirect
>     >>>     >>>         >>         # there to take us to the new location
>     >>>     >>>         >>     "name": "libwebsockets.org
>     <http://libwebsockets.org> <
>     >>> http://libwebsockets.org>
>     >>>     ><http://libwebsockets.org>",
>     >>>     >>>
>     >>>     >>>         >>     "port": "7681",
>     >>>     >>>         >>      "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": [{
>     >>>     >>>         >>        "mountpoint": "/",
>     >>>     >>>         >>        "origin": ">
>     >>> https://libwebsockets.org/testserver/"
>     >>>     >>>         >>      }]
>     >>>     >>>         >>   }
>     >>>     >>>         >> You should be able to give an origin like
>     >>>     >>>         >> "origin":
>     >">https://libwebsockets.org:7681/testserver/
>     >>> "
>     >>>     >>>         >>
>     >>>     >>>         >> vhost need plugin support if I understood
>     >correctly. If
>     >>>     >yes,
>     >>>     >>>         then I
>     >>>     >>>         >don't
>     >>>     >>>         >see how to make it work with vhost
>     >>>     >>>
>     >>>     >>>         No: vhosts are baked into the main lib and are
>     >unrelated
>     >>> to
>     >>>     >>> plugins.
>     >>>     >>>
>     >>>     >>>         You can deliver an array of protocols to them when
>     >you
>     >>>     >create
>     >>>     >>>         them, and you mention protocol names in the info.pvo
>     >>> linked
>     >>>     >list
>     >>>     >>>         to enable + configure them on the vhost.
>     >>>     >>>
>     >>>     >>>         If plugins are enabled, lws will bind any protocol
>     >names
>     >>> to
>     >>>     >the
>     >>>     >>>         plugin that matches, at init time; it makes a new
>     >>> protocols
>     >>>     >>>         array if so with your array and then any dynamically
>     >found
>     >>>     >>>         protocols enabled by mentions in pvo appended.  But
>     >it's
>     >>>     >>>         completely optional, you can do everything just with
>     >the
>     >>>     >static
>     >>>     >>>         array of protocols you fed the vhost and no plugins,
>     >since
>     >>>     >>>         vhosts only talks about protocols using their name,
>     >it
>     >>>     >doesn't
>     >>>     >>>         care where it found them originally.
>     >>>     >>>
>     >>>     >>>         -Andy
>     >>>     >>>
>     >>>     >>>         >
>     >>>     >>>         >
>     >>>     >>>         >2016-05-26 16:13 GMT+02:00 Andy Green
>     ><andy at warmcat.com <mailto:andy at warmcat.com>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     >>>         <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     ><mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>:
>     >>>     >>>
>     >>>     >>>         >
>     >>>     >>>         >>
>     >>>     >>>         >>
>     >>>     >>>         >> On 05/26/2016 08:40 PM, Thomas Spitz wrote:
>     >>>     >>>         >>
>     >>>     >>>         >>>     Maybe you should better prototype it with
>     >the high
>     >>>     >end
>     >>>     >>>         stuff and
>     >>>     >>>         >>>     when it works, look at reducing that to
>     >code,
>     >>>     >including
>     >>>     >>> the
>     >>>     >>>         >plugin
>     >>>     >>>         >>>     content direct in your app etc if you still
>     >want
>     >>> to.
>     >>>     >>>         >>>
>     >>>     >>>         >>> This is what I have done. First lwsws, then
>     >>>     >test-server-v2.0
>     >>>     >>>         then
>     >>>     >>>         >>> test-server then my program
>     >>>     >>>         >>>
>     >>>     >>>         >>> This leads me to use lws in the old manner
>     >because my
>     >>>     >main ws
>     >>>     >>>         >protocol
>     >>>     >>>         >>> (which is part of my program) cannot be launched
>     >as
>     >>>     >plugin
>     >>>     >>>         (too much
>     >>>     >>>         >>> work to make it work as separate program and
>     >also too
>     >>>     >hard
>     >>>     >>>         to debug
>     >>>     >>>         >then)
>     >>>     >>>         >>>
>     >>>     >>>         >>
>     >>>     >>>         >> I don't really understand your situation, but it
>     >is
>     >>> not a
>     >>>     >>>         separate
>     >>>     >>>         >> program.  As I mentioned the one plugin can
>     >service
>     >>> both
>     >>>     >ws
>     >>>     >>>         and http
>     >>>     >>>         >in the
>     >>>     >>>         >> one callback function.  Maybe I misunderstand.
>     >>>     >>>         >>
>     >>>     >>>         >> I will unfortunately have to implement low-level
>     >code
>     >>> for
>     >>>     >>>         static (GET
>     >>>     >>>         >>> file like leaf.png with/without
>     >authentification) and
>     >>>     >>>         dynamic (HTTP
>     >>>     >>>         >>> GET/POST command) HTTP serving.
>     >>>     >>>         >>>
>     >>>     >>>         >>
>     >>>     >>>         >> Can you tell a little more about why you "have"
>     >to do
>     >>> the
>     >>>     >low
>     >>>     >>>         level
>     >>>     >>>         >> serving code for static files?  If it's auth, the
>     >>>     >>>         generic-sessions
>     >>>     >>>         >plugin
>     >>>     >>>         >> is aimed at providing that.  If there's something
>     >>> special
>     >>>     >>>         about your
>     >>>     >>>         >auth
>     >>>     >>>         >> needs, I am very curious to hear about that atm.
>     >>>     >Generally I
>     >>>     >>>         am very
>     >>>     >>>         >much
>     >>>     >>>         >> trying to provide static file serving with
>     >session auth
>     >>>     >"out
>     >>>     >>>         of the
>     >>>     >>>         >box".
>     >>>     >>>         >>
>     >>>     >>>         >> I agree you'll have to do your own dynamic HTTP
>     >serving
>     >>>     >code,
>     >>>     >>> but
>     >>>     >>>         >this can
>     >>>     >>>         >> coexist in the same plugin - the same source file
>     >- as
>     >>>     >the ws
>     >>>     >>>         serving
>     >>>     >>>         >part,
>     >>>     >>>         >> if that helps.
>     >>>     >>>         >>
>     >>>     >>>         >> Hope you will keep test-server always up to date
>     >>>     >>>         >>>
>     >>>     >>>         >>> One minor question : Is it possible to do port
>     >>>     >redirection
>     >>>     >>> with
>     >>>     >>>         >>> test-server (http 80 -> redirect to https 7681).
>     >By
>     >>> the
>     >>>     >way
>     >>>     >>> one
>     >>>     >>>         >drawback
>     >>>     >>>         >>>
>     >>>     >>>         >>
>     >>>     >>>         >> Sure... you make a vhost at the port you want to
>     >>>     >redirect,
>     >>>     >>>         and tell
>     >>>     >>>         >it the
>     >>>     >>>         >> new URL in the origin  (This one redirects SSL on
>     >port
>     >>>     >7681,
>     >>>     >>>         where I
>     >>>     >>>         >used
>     >>>     >>>         >> to run the test server, to SSL on port 443 and
>     >the URL
>     >>>     >where
>     >>>     >>>         it now
>     >>>     >>>         >lives)
>     >>>     >>>         >>
>     >>>     >>>         >>     {
>     >>>     >>>         >>         # the old test server ran this on :7681,
>     >put a
>     >>>     >redirect
>     >>>     >>>         >>         # there to take us to the new location
>     >>>     >>>         >>     "name": "libwebsockets.org
>     <http://libwebsockets.org> <
>     >>> http://libwebsockets.org>
>     >>>     ><http://libwebsockets.org>",
>     >>>     >>>
>     >>>     >>>         >>     "port": "7681",
>     >>>     >>>         >>      "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": [{
>     >>>     >>>         >>        "mountpoint": "/",
>     >>>     >>>         >>        "origin": ">
>     >>> https://libwebsockets.org/testserver/"
>     >>>     >>>         >>      }]
>     >>>     >>>         >>   }
>     >>>     >>>         >>
>     >>>     >>>         >> You should be able to give an origin like
>     >>>     >>>         >>
>     >>>     >>>         >> "origin":
>     >">https://libwebsockets.org:7681/testserver/
>     >>> "
>     >>>     >>>         >>
>     >>>     >>>         >> with redirection using lwsws is that we have to
>     >>> specify a
>     >>>     >URL
>     >>>     >>>         when
>     >>>     >>>         >doing
>     >>>     >>>         >>> port redirection. For instance if we have server
>     >at
>     >>>     >>> 192.168.1.3
>     >>>     >>>         >exposed
>     >>>     >>>         >>> to the web as websockets.org
>     <http://websockets.org>
>     ><http://websockets.org>
>     >>>     <http://websockets.org>
>     >>>     >>>         <http://websockets.org> then we need
>     >>>     >>>         >two
>     >>>     >>>         >>> redirections in order to make it work on both
>     >LAN and
>     >>>     >WAN
>     >>>     >>>         >>>
>     >>>     >>>         >>
>     >>>     >>>         >> Hm you can configure your local DNS to tell you
>     >>>     >192.168.1.3
>     >>>     >>>         is the
>     >>>     >>>         >address
>     >>>     >>>         >> of your server, to local clients.  That's what I
>     >do
>     >>> here
>     >>>     >to
>     >>>     >>>         access my
>     >>>     >>>         >own
>     >>>     >>>         >> internet-facing services.
>     >>>     >>>         >>
>     >>>     >>>         >> If it's a laptop and you take it outside, he gets
>     >>>     >external
>     >>>     >>>         DNS server
>     >>>     >>>         >and
>     >>>     >>>         >> uses the external address automatically.
>     >>>     >>>         >>
>     >>>     >>>         >> That's not really an lws problem, if I understood
>     >it.
>     >>>     >>>         >>
>     >>>     >>>         >> -Andy
>     >>>     >>>         >>
>     >>>     >>>         >> Thanks for the support.
>     >>>     >>>         >>>
>     >>>     >>>         >>> Best regards,
>     >>>     >>>         >>> Thomas
>     >>>     >>>         >>>
>     >>>     >>>         >>> 2016-05-26 11:48 GMT+02:00 Andy Green
>     >>>     <andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     >>>         <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com> <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>>>
>     >>>     >>>         >>> <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>
>     ><mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>>:
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>     On 05/26/2016 05:15 PM, Thomas Spitz wrote:
>     >>>     >>>         >>>
>     >>>     >>>         >>>         Hello Andy,
>     >>>     >>>         >>>
>     >>>     >>>         >>>         On one hand, I have tried to use the new
>     >>> plugin
>     >>>     >>>         approach in
>     >>>     >>>         >my
>     >>>     >>>         >>>         program
>     >>>     >>>         >>>         but it is very hard in my case because
>     >lws
>     >>>     >server and
>     >>>     >>> my
>     >>>     >>>         >main
>     >>>     >>>         >>>         plugin (ws
>     >>>     >>>         >>>         connection) are very tied together (they
>     >share
>     >>>     >many
>     >>>     >>>         >variables
>     >>>     >>>         >>>         that would
>     >>>     >>>         >>>         need to be exposed to my application
>     >through
>     >>> shm
>     >>>     >or
>     >>>     >>>         other
>     >>>     >>>         >>>         sharing options).
>     >>>     >>>         >>>         On the other hand, in order to get
>     >advantage
>     >>> of
>     >>>     >>>         better HTTP
>     >>>     >>>         >file
>     >>>     >>>         >>>         handling, auth management and further
>     >>>     >improvements,
>     >>>     >>>         I would
>     >>>     >>>         >like
>     >>>     >>>         >>>         not to
>     >>>     >>>         >>>         have to write my own callback_http.
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>     If you are going to serve dynamic http,
>     >you'll
>     >>> need
>     >>>     >to
>     >>>     >>>         have your
>     >>>     >>>         >own
>     >>>     >>>         >>>     http handling.  But that can be in the same
>     >>> plugin -
>     >>>     >the
>     >>>     >>>         same
>     >>>     >>>         >>>     protocol callback - as the ws parts, so
>     >there is
>     >>> no
>     >>>     >>> problem
>     >>>     >>>         >about
>     >>>     >>>         >>>     "sharing variables".
>     >>>     >>>         >>>
>     >>>     >>>         >>>         In other word, is it possible to declare
>     >my
>     >>> own
>     >>>     >>> protocol
>     >>>     >>>         >>>         definitions and
>     >>>     >>>         >>>         user callback contents like in first
>     >>> test-server
>     >>>     >but
>     >>>     >>>         without
>     >>>     >>>         >>>         declaring
>     >>>     >>>         >>>         http-callback. That is to say
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>     If you need it, because you're not serving
>     >files
>     >>> but
>     >>>     >>>         generated
>     >>>     >>>         >html,
>     >>>     >>>         >>>     you need it.  If you're serving files, like
>     >>>     >leaf.jpg,
>     >>>     >>>         you can
>     >>>     >>>         >use
>     >>>     >>>         >>>     mounts.
>     >>>     >>>         >>>
>     >>>     >>>         >>>              /* list of supported protocols and
>     >>>     >callbacks */
>     >>>     >>>         >>>              static struct lws_protocols
>     >protocols[] =
>     >>>     >>>         >>>              {
>     >>>     >>>         >>>              { "MY_PROTOCOL",
>     >callback_my_protocol,
>     >>>     >>>         sizeof(struct
>     >>>     >>>         >>>              per_session_data__my_protocole),
>     >4096},
>     >>>     >>>         >>>              { NULL, NULL, 0, 0 } /* terminator
>     >*/
>     >>>     >>>         >>>              };
>     >>>     >>>         >>>
>     >>>     >>>         >>>     ...
>     >>>     >>>         >>>
>     >>>     >>>         >>>         it is not clear for me wether libuv (and
>     >so
>     >>>     >plugins)
>     >>>     >>> are
>     >>>     >>>         >>>         required or nor.
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>     Lws is pretty flexible, it does not itself
>     >need
>     >>>     >libuv or
>     >>>     >>>         >plugins.
>     >>>     >>>         >>>     But you are into writing a lot of code and
>     >structs
>     >>>     >if you
>     >>>     >>> go
>     >>>     >>>         >that way.
>     >>>     >>>         >>>
>     >>>     >>>         >>>     One of the knock-ons is then you must
>     >provide an
>     >>>     >explicit
>     >>>     >>>         >http-only
>     >>>     >>>         >>>     protocols[0] yourself.
>     >>>     >>>         >>>
>     >>>     >>>         >>>     If you use the plugins stuff, actually you
>     >can
>     >>> avoid
>     >>>     >it
>     >>>     >>> -->
>     >>>     >>>         >>>
>     >>>     >>>         >>>         I also do not understand how
>     >test-server-v2.0
>     >>>     >manage
>     >>>     >>> to
>     >>>     >>>         >serve
>     >>>     >>>         >>>         leaf.png
>     >>>     >>>         >>>         and any other file in any other folder
>     >(what
>     >>>     >>> test-server
>     >>>     >>>         >isn't
>     >>>     >>>         >>>         able to
>     >>>     >>>         >>>         do) using HTTP
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>     test-server-v2.0.c is even more remarkable
>     >if you
>     >>>     >notice
>     >>>     >>> he
>     >>>     >>>         >doesn't
>     >>>     >>>         >>>     define any protocols at all.  Lws defines a
>     >dummy
>     >>>     >>>         "protocols[0]"
>     >>>     >>>         >one
>     >>>     >>>         >>>     then and assembles the protocol structs
>     >>> dynamically
>     >>>     >from
>     >>>     >>> the
>     >>>     >>>         >plugins
>     >>>     >>>         >>>     enabled in the config (or info.pvo if you do
>     >it by
>     >>>     >hand
>     >>>     >>> with
>     >>>     >>>         >structs).
>     >>>     >>>         >>>
>     >>>     >>>         >>>     The reason it can serve everything is it
>     >declares
>     >>> a
>     >>>     >mount:
>     >>>     >>>         >>>
>     >>>     >>>         >>>     static const struct lws_http_mount mount = {
>     >>>     >>>         >>>              (struct lws_http_mount
>     >*)&mount_post,
>     >>>     >>>  /*
>     >>>     >>>         >>>     linked-list pointer to next*/
>     >>>     >>>         >>>              "/",            /* mountpoint in
>     >URL
>     >>>     >namespace
>     >>>     >>>         on this
>     >>>     >>>         >vhost
>     >>>     >>>         >>> */
>     >>>     >>>         >>>              LOCAL_RESOURCE_PATH, /* where to go
>     >on
>     >>> the
>     >>>     >>>         filesystem
>     >>>     >>>         >for
>     >>>     >>>         >>>     that */
>     >>>     >>>         >>>              "test.html",    /* default filename
>     >if
>     >>> none
>     >>>     >>>         given */
>     >>>     >>>         >>>              NULL,
>     >>>     >>>         >>>              NULL,
>     >>>     >>>         >>>              NULL,
>     >>>     >>>         >>>              NULL,
>     >>>     >>>         >>>              0,
>     >>>     >>>         >>>              0,
>     >>>     >>>         >>>              0,
>     >>>     >>>         >>>              0,
>     >>>     >>>         >>>              0,
>     >>>     >>>         >>>              0,
>     >>>     >>>         >>>              LWSMPRO_FILE,   /* mount type is a
>     >>>     >directory in a
>     >>>     >>>         >filesystem
>     >>>     >>>         >>> */
>     >>>     >>>         >>>              1,              /* strlen("/"), ie
>     >length
>     >>>     >of the
>     >>>     >>>         >mountpoint
>     >>>     >>>         >>> */
>     >>>     >>>         >>>     };
>     >>>     >>>         >>>
>     >>>     >>>         >>>     binding the URL namespace from / to
>     >>>     >LOCAL_RESOURCE_PATH,
>     >>>     >>>         which
>     >>>     >>>         >is
>     >>>     >>>         >>>     /usr/share/libwebsockets-test-server or
>     >wherever
>     >>> you
>     >>>     >>>         installed
>     >>>     >>>         >lws.
>     >>>     >>>         >>>
>     >>>     >>>         >>>     Once you set it up, unless it finds another
>     >mount
>     >>>     >that's a
>     >>>     >>>         >better
>     >>>     >>>         >>>     match to the URL, lws will automatically
>     >serve
>     >>> files
>     >>>     >>>         from that
>     >>>     >>>         >dir
>     >>>     >>>         >>>     when asked for things in /.  leaf.jpg is in
>     >that
>     >>>     >>> directory.
>     >>>     >>>         >>>
>     >>>     >>>         >>>     The equivalent bit of lwsws conf is this
>     >>>     >>>         >>>
>     >>>     >>>         >>>             {
>     >>>     >>>         >>>             "mountpoint": "/",
>     >>>     >>>         >>>             "origin":
>     >>>     >>>         "file:///usr/share/libwebsockets-test-server",
>     >>>     >>>         >>>             "default": "test.html",
>     >>>     >>>         >>>             }
>     >>>     >>>         >>>
>     >>>     >>>         >>>     Lws lets you also declare mounts that are
>     >bound
>     >>> to a
>     >>>     >>>         protocol
>     >>>     >>>         >name.
>     >>>     >>>         >>>
>     >>>     >>>         >>>             {
>     >>>     >>>         >>>              "mountpoint": "/dynamic",
>     >>>     >>>         >>>              "origin":
>     >"callback://my-protocol-name"
>     >>>     >>>         >>>             }
>     >>>     >>>         >>>
>     >>>     >>>         >>>     HTTP GET or POST down /dynamic/* will occur
>     >on the
>     >>>     >>>         callback for
>     >>>     >>>         >>>     "my-protocol-name". (The name /dynamic is
>     >not
>     >>>     >meaningful,
>     >>>     >>> it
>     >>>     >>>         >could
>     >>>     >>>         >>>     be anything).
>     >>>     >>>         >>>
>     >>>     >>>         >>>     So this way you can automate serving static
>     >>> content
>     >>>     >so
>     >>>     >>>         it is no
>     >>>     >>>         >>>     effort, and isolate serving dynamic content
>     >for a
>     >>>     >region
>     >>>     >>>         of the
>     >>>     >>>         >URL
>     >>>     >>>         >>>     space in a plugin, by name.
>     >>>     >>>         >>>
>     >>>     >>>         >>>         As you can see I am quite confusing with
>     >all
>     >>> the
>     >>>     >new
>     >>>     >>>         >>>         possibilities. If
>     >>>     >>>         >>>         my questions are not clear, I can send
>     >you
>     >>> part
>     >>>     >of my
>     >>>     >>>         >code...
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>     It's difficult to answer in a more
>     >straightforward
>     >>>     >way
>     >>>     >>>         because
>     >>>     >>>         >the
>     >>>     >>>         >>>     best solution is pushing to make it as
>     >abstract as
>     >>>     >>> possible
>     >>>     >>>         >(lwsws,
>     >>>     >>>         >>>     libuv, protocol plugins) but you want to
>     >implement
>     >>>     >it all
>     >>>     >>> in
>     >>>     >>>         >code.
>     >>>     >>>         >>>     So while explaining you should use plugins
>     >you're
>     >>>     >also
>     >>>     >>>         asking
>     >>>     >>>         >how to
>     >>>     >>>         >>>     do it without them.
>     >>>     >>>         >>>
>     >>>     >>>         >>>     Maybe you should better prototype it with
>     >the high
>     >>>     >end
>     >>>     >>>         stuff and
>     >>>     >>>         >>>     when it works, look at reducing that to
>     >code,
>     >>>     >including
>     >>>     >>> the
>     >>>     >>>         >plugin
>     >>>     >>>         >>>     content direct in your app etc if you still
>     >want
>     >>> to.
>     >>>     >>>         >>>
>     >>>     >>>         >>>     -Andy
>     >>>     >>>         >>>
>     >>>     >>>         >>>         Best regards,
>     >>>     >>>         >>>         Thomas
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>         2016-05-18 9:06 GMT+02:00 Andy Green
>     >>>     >>>         <andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>
>     >>>     >>>         >>>         <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     ><mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>
>     >>>     >>>         >>>         <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     ><mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>
>     >>>     >>>         <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com> <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>>>:
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>              On May 18, 2016 2:46:13 PM
>     >GMT+08:00,
>     >>>     >Thomas
>     >>>     >>> Spitz
>     >>>     >>>         >>>              <thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>
>     >>>     >>>         <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>>
>     >>>     >>>         >>>
>      <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>
>     >>>     >>>         <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>>>
>     >>>     >>>         >>>
>     ><mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>
>     >>>     >>>         <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>>
>     >>>     >>>         >>>
>     >>>     >>>         >>>
>      <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>
>     >>>     >>>         <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>
>     >>>     <mailto:thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>>>>>> wrote:
>     >>>     >>>         >>>              >Hello Andy,
>     >>>     >>>         >>>              >
>     >>>     >>>         >>>              >I think I will use plugins however
>     >>>     >regarding
>     >>>     >>>         lwsws I
>     >>>     >>>         >will
>     >>>     >>>         >>>         rather not
>     >>>     >>>         >>>              >use it
>     >>>     >>>         >>>
>     >>>     >>>         >>>              That'll get you most of the
>     >benefits.
>     >>>     >>>         >>>
>     >>>     >>>         >>>              >because my application need to
>     >>> computably
>     >>>     >>>         >computationally
>     >>>     >>>         >>>         (not
>     >>>     >>>         >>>              >manually)
>     >>>     >>>         >>>              >configure ports, redirect and
>     >protocols.
>     >>>     >Thus,
>     >>>     >>>         I think
>     >>>     >>>         >>>         going through
>     >>>     >>>         >>>              >JSON
>     >>>     >>>         >>>              >files will certainly be more
>     >complex
>     >>> than
>     >>>     >>>         dealing with
>     >>>     >>>         >>>         native C
>     >>>     >>>         >>>              >structures... I might be wrong...
>     >>>     >>>         >>>
>     >>>     >>>         >>>              You know your application better
>     >than I
>     >>>     >do...
>     >>>     >>>         if it's
>     >>>     >>>         >>>         easier to wire
>     >>>     >>>         >>>              up with structs, no problem.
>     >>>     >>>         >>>
>     >>>     >>>         >>>              One observation though... JSON is
>     >easy to
>     >>>     >>>         >machine-generate
>     >>>     >>>         >>>         if need be.
>     >>>     >>>         >>>
>     >>>     >>>         >>>              -Andy
>     >>>     >>>         >>>
>     >>>     >>>         >>>               >Best regards,
>     >>>     >>>         >>>               >Thomas
>     >>>     >>>         >>>               >
>     >>>     >>>         >>>               >
>     >>>     >>>         >>>               >2016-05-17 20:48 GMT+02:00 Andy
>     >Green
>     >>>     >>>         ><andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>
>     >>>     >>>         >>>         <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     ><mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>
>     >>>     >>>         >>>              <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     >>>         <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com> <mailto:andy at warmcat.com
>     <mailto:andy at warmcat.com>>>
>     >>>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>     >>>     >>>         <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>     ><mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>>>:
>     >>>     >>>         >>>               >
>     >>>     >>>         >>>               >>
>     >>>     >>>         >>>               >>
>     >>>     >>>         >>>               >> On May 18, 2016 1:43:04 AM
>     >GMT+08:00,
>     >>
>     >>
>
>



More information about the Libwebsockets mailing list