[Libwebsockets] v2.0 coming very soon

Thomas Spitz thomas.spitz at hestia-france.com
Mon Jun 13 16:49:16 CEST 2016


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



2016-06-13 15:45 GMT+02:00 Andy Green <andy at warmcat.com>:

>
>
> On June 13, 2016 9:13:40 PM GMT+08:00, Thomas Spitz <
> 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>:
> >
> >>
> >>
> >> 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>>:
> >>>
> >>>
> >>>
> >>>     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>> 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>>:
> >>>     >
> >>>     >>
> >>>     >>
> >>>     >> 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>, 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>>>
> >>>     >>>     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>
> >>>     >>>
> >>>     >>>         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>
> >>>     >>>         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>>>:
> >>>     >>>
> >>>     >>>     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>>>:
> >>>     >>>
> >>>     >>>
> >>>     >>>
> >>>     >>>         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>>> 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>",
> >>>     >>>
> >>>     >>>         >>     "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>>>:
> >>>     >>>
> >>>     >>>         >
> >>>     >>>         >>
> >>>     >>>         >>
> >>>     >>>         >> 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>",
> >>>     >>>
> >>>     >>>         >>     "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> 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>>>>:
> >>>     >>>         >>>
> >>>     >>>         >>>
> >>>     >>>         >>>
> >>>     >>>         >>>
> >>>     >>>         >>>     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>>>>>:
> >>>     >>>         >>>
> >>>     >>>         >>>
> >>>     >>>         >>>
> >>>     >>>         >>>              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>>>>> 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>>>>>:
> >>>     >>>         >>>               >
> >>>     >>>         >>>               >>
> >>>     >>>         >>>               >>
> >>>     >>>         >>>               >> On May 18, 2016 1:43:04 AM
> >GMT+08:00,
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160613/eead985b/attachment-0001.html>


More information about the Libwebsockets mailing list