[Libwebsockets] v2.0 coming very soon

Thomas Spitz thomas.spitz at hestia-france.com
Thu Jun 2 18:21:08 CEST 2016


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.

So I wanted to use vhost LWSMPRO_CALLBACK functionnality but apparently it
is bind to plugin approach... So bad for me ;-)

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)

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.


Best regadrs,
Thomas

2016-06-02 12:46 GMT+02:00 Andy Green <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, 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>>
>>     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>
>>
>>         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>
>>         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>>:
>>
>>     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>>:
>>
>>
>>
>>         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>> 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>",
>>
>>         >>     "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>>:
>>
>>         >
>>         >>
>>         >>
>>         >> 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>",
>>
>>         >>     "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> 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>>>:
>>         >>>
>>         >>>
>>         >>>
>>         >>>
>>         >>>     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>>>>:
>>         >>>
>>         >>>
>>         >>>
>>         >>>              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>>>> 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>>>>:
>>         >>>               >
>>         >>>               >>
>>         >>>               >>
>>         >>>               >> On May 18, 2016 1:43:04 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>>
>>         >>>              <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:
>>         >>>               >> >I think I will have to go for option 1 as
>> you
>>         >explained
>>         >>> in
>>         >>>               >>
>>         >>>
>>         >>>           >>
>>         >>>
>>         >
>> https://libwebsockets.org/pipermail/libwebsockets/2016-April/002303.html
>>         >>>               >> >in
>>         >>>               >> >order to get an easy and maintainable
>>         solution for
>>         >port
>>         >>>               >redirections,
>>         >>>               >> >http
>>         >>>               >> >processing, ...:
>>         >>>               >>
>>         >>>               >> It's workable, but compared to just having
>>         a custom
>>         >>>         JSON config
>>         >>>              and a
>>         >>>               >> plugin, with everything else off the shelf,
>>         it's
>>         >not
>>         >>>         the easiest or
>>         >>>               >most
>>         >>>               >> maintainable way.
>>         >>>               >>
>>         >>>               >> >1) Keep your existing code and attach your
>> own
>>         >mounts
>>         >>>         at vhost
>>         >>>               >creation
>>         >>>               >> >time
>>         >>>               >> >
>>         >>>               >> >
>>         >>>               >>
>>         >>>
>>         >>>           >
>>         >>>
>>         >
>> https://github.com/warmcat/libwebsockets/blob/master/README.coding.md#using-lws-v2-vhosts
>>         >>>               >> >
>>         >>>               >> >Lws will serve the mounted contents
>>         automatically
>>         >from
>>         >>>         where it's
>>         >>>               >> >mounted
>>         >>>               >> >in the server namespace
>>         >>>               >> >
>>         >>>               >> >Could you confirm that this solution
>> requires
>>         >libuv
>>         >>>         and or libev? I
>>         >>>               >> >hope
>>         >>>               >> >this will not stress too much my emdedded
>>         system
>>         >;-)
>>         >>>               >>
>>         >>>               >> Plugins are what implies libuv (not libev).
>>         >However I
>>         >>>         think you
>>         >>>              find
>>         >>>               >for
>>         >>>               >> Arm v7 running Linux, the idea libuv will
>>         'strain'
>>         >it
>>         >>>         is probably
>>         >>>               >just
>>         >>>               >> prejudice.  Libuv is cheap as a crossplatform
>>         >wrapper
>>         >>>         around socket
>>         >>>               >events
>>         >>>               >> or timers, and we're otherwise using it for
>>         >>>         crossplatform dirent and
>>         >>>               >plugin
>>         >>>               >> operations at init.
>>         >>>               >>
>>         >>>               >> Until recently when it got updated to a Rpi
>> 3,
>>         >>>         libwebsockets.org <http://libwebsockets.org>
>>         <http://libwebsockets.org>
>>         >>>              <http://libwebsockets.org> was
>>         >>>
>>         >>>               >a
>>         >>>               >> 1GHz Armv7, before that a series of weaker
>> Arm
>>         >devices
>>         >>>         like CA8,
>>         >>>              even
>>         >>>               >the
>>         >>>               >> weakest ones with 256MB would have had no
>>         trouble
>>         >with
>>         >>>         libuv in the
>>         >>>               >mix.
>>         >>>               >>
>>         >>>               >> >I think this would have been nice to have
>>         cgitest,
>>         >>>         server-status in
>>         >>>               >> >libwebsockets-test-server-v2.0 and
>>         >>>         libwebsockets-test-server to
>>         >>>               >compare
>>         >>>               >> >the
>>         >>>               >> >three solutions (the third solution is
>> lwsws).
>>         >>>               >>
>>         >>>               >> The old test server code is bloated with
>> adding
>>         >support
>>         >>>         for the
>>         >>>               >kitchen
>>         >>>               >> sink in there, making it difficult to use
>>         as the
>>         >>>         example it's
>>         >>>               >intended to
>>         >>>               >> be; the advantage of the plugins + lwsws for
>>         >>>         maintainability is
>>         >>>               >clear.
>>         >>>               >>
>>         >>>               >> You can add everything in the plugins +
>>         lwsws JSON
>>         >into
>>         >>>               >test-server-v2.0.c
>>         >>>               >> as structs + protocols + api calls, but then
>> it
>>         >will
>>         >>> become
>>         >>>               >inflexible and
>>         >>>               >> huge... that's a big step backwards.
>>         >>>               >>
>>         >>>               >> So the official test-server-v2.0.c should
>>         stay like
>>         >it
>>         >>>         is, just
>>         >>>               >having
>>         >>>               >> enough 'config by struct' to demonstrate the
>>         >concept
>>         >>>         and leveraging
>>         >>>               >the
>>         >>>               >> plugins, where a standalone server app is
>>         possible
>>         >>>         lwsws is the way
>>         >>>               >to 'do
>>         >>>               >> everything' flexibly and maintainably.
>>         >>>               >>
>>         >>>               >> >libwebsockets-test-server is
>>         >>>               >> >probably not necessary as I assume it will
>>         be a
>>         >>>         depreciated
>>         >>>              solution
>>         >>>               >in
>>         >>>               >> >the
>>         >>>               >> >future? I will certainly try to complete
>>         >>>               >libwebsockets-test-server-v2.0
>>         >>>               >> >tomorrow.
>>         >>>               >>
>>         >>>               >> Yes the old all-in-one test server will
>>         continue to
>>         >be
>>         >>>         supported
>>         >>>               >(indeed
>>         >>>               >> the default, since everything else needs
>>         enabling
>>         >at
>>         >>>         cmake).
>>         >>>              But new
>>         >>>               >stuff
>>         >>>               >> - I plan to discuss a completely new, highly
>>         >abstracted
>>         >>>         protocol
>>         >>>               >plugin
>>         >>>               >> project soon, and suitable third-party
>> plugins
>>         >could
>>         >>>         become provided
>>         >>>               >as
>>         >>>               >> part of lws - will be provided as 'mix and
>>         >matchable'
>>         >>>         standalone
>>         >>>               >plugins
>>         >>>               >> only.
>>         >>>               >>
>>         >>>               >> -Andy
>>         >>>               >>
>>         >>>               >> >Best regards,
>>         >>>               >> >Thomas
>>         >>>               >>
>>         >>>               >>
>>         >>>
>>         >>>
>>         >>>
>>         >>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160602/06b5a9bc/attachment-0001.html>


More information about the Libwebsockets mailing list