This adds
- simple lws_urlencode()
- simple lws_urldecode()
- simple lws_sql_purify
Those expect the data to all be there and process it up until
the first '\0'.
There is also a larger opaque apis for handling POST_BODY urldecode. To
enable these, you need to give cmake -DLWS_WITH_STATEFUL_URLDECODE=1 (or
arrange any larger feature that relies on it sets that in CMakeLists.txt)
- stateful urldecode with parameter array
These have create / process / destroy semantics on a struct that maintains
decode state.
Stateful urldecode is capable of dealing with large POST data in multiple
POST_BODY callbacks cleanly, eg, file transfer by POST.
Stateful urldecode with parameter array wraps the above with a canned
callback that stores the urldecoded data and indexes them in a pointer
array matching an array of parameter names.
You may also pass it an optional callback when creating it, that will recieve
uploaded file content.
The test html is updated to support both urlencoded and multipart forms,
with some javascript to do clientside validation of an arbitrary 100KB
file size limit (there is no file size limit in the apis).
Signed-off-by: Andy Green <andy@warmcat.com>
This is used to confirm that SSL client connections can coexist with
a vhost doing serving.
To set it up,
/*
* This is a bit fiddly...
*
* 0) If you want the wss:// test to work, make sure the vhost is marked with
* enable-client-ssl if using lwsws, or call lws_init_vhost_client_ssl() on
* the vhost if you're doing it by hand.
*
* 1) enable the protocol on a vhost
*
* "ws-protocols": [{
* "client-loopback-test": {
* "status": "ok"
* }, ...
*
* the vhost should listen on 80 (ws://) or 443 (wss://)
*
* 2) mount the http part of the test one level down on the same vhost, eg
* {
* "mountpoint": "/c",
* "origin": "callback://client-loopback-test"
* }
*
* 3) Use a browser to visit the mountpoint with a URI attached for looping
* back, eg, if testing on localhost
*
* http://localhost/c/ws://localhost
* https://localhost/c/wss://localhost
*
* 4) The HTTP part of this test protocol will try to do the requested
* ws client connection, to the same test protocol on the same
* server.
*/
Results should look like this
lwsws[29938]: client connection to localhost:443 with ssl: 1 started
lwsws[29938]: server part: LWS_CALLBACK_ESTABLISHED
lwsws[29938]: checking client ext permessage-deflate
lwsws[29938]: instantiating client ext permessage-deflate
lwsws[29938]: Client connection established
lwsws[29938]: Client connection received 7 from server 'Made it'
Signed-off-by: Andy Green <andy@warmcat.com>
Actually lwsws doesn't need his own protocol handler even for http
any more. The default http handler in lws should do everything.
Move the cgi routing into lws default http protocol handler, and
delete lwsws one. Remove all protocols from lwsws so the lws
default one gets used.
With this, and the earlier move of lejp into lws, lwsws itself
becomes 15.5KB of x86_64 (mainly conf parsing).
Signed-off-by: Andy Green <andy@warmcat.com>
lejp is already in lws as part of lwsws. However it's too generally useful
to just put directly in lwsws, it will lead to multiple copies of the source
in differet subprojects.
This moves it directly into lws, lwsws now gets it from there.
Like lwsws, by default at cmake it is disabled. Selecting LWS_WITH_LWSWS now
selects LWS_WITH_LEJP and you can set that at cmake individually as well.
Signed-off-by: Andy Green <andy@warmcat.com>
No dependency on test-server.h (just libwebsockets.h and getopt.h / syslog.h)
No need for any user callback code and all in one short file.
Signed-off-by: Andy Green <andy@warmcat.com>
This allows mounts to define the caching policy of the files inside them.
Support is added in lwsws for controlling it from the config files.
The api for serializing a mount struct opaquely is removed and lws_http_mount struct
made public... it was getting out of control trying to hide the options.
Signed-off-by: Andy Green <andy@warmcat.com>
This adds the ability to store apache-compatible logs to a file given at
vhost-creation time.
lwsws conf can set it per-vhost using "access-log": "<filepath>"
The feature defaults to disabled at cmake, it can be set independently but
LWS_WITH_LWSWS set it on.
Signed-off-by: Andy Green <andy@warmcat.com>
After discussion here
https://libwebsockets.org/pipermail/libwebsockets/2016-April/002268.html
scandir usage in
- lwsws conf.c
- lws plugin support
and
- lws plugin apis for dl
are converted to us libuv apis so they can work cross-platform easily.
lws itself remains not requiring libuv, although it's an option.
- LWS_WITH_LWSWS
- LWS_WITH_PLUGINS
now force LWS_WITH_LIBUV if selected... both of these are new features
only in master atm and both are off by default in CMake.
There's a complication libuv can be too old to offer the necessary apis,
this is the case in Travis Trusty instance. In that case, UV_VERSION_MAJOR ==0,
then the unix-only plugin implementation is used instead.
Signed-off-by: Andy Green <andy@warmcat.com>
This adds support for dynamically loaded plugins at runtime, which
can expose their own protocols or extensions transparently.
With these changes lwsws defaults to OFF in cmake, and if enabled it
automatically enables plugins and libuv support.
Signed-off-by: Andy Green <andy@warmcat.com>
polarssl is the old name for mbedtls. Unfortunately the two are confused in eg,
Fedora. For our purposes, polarssl or mbedtls < 2.0 has includes in
/usr/include/polarssl and polarssl_ apis and we call that "polarssl".
polarssl or mbedtls >=2.0 has includes in /usr/include/mbedtls and mbedtls_ apis,
we call that "mbedtls".
This has to be spelled out clearly because eg Fedora has a package "mbedtls" which
is 1.3.x and has the polarssl_ apis and include path. We will deal with that as
"polarssl" despite the package name then.
This patch lets you use LWS_USE_POLARSSL or LWS_USE_MBEDTLS and set the include and
library path like this
cmake .. -DLWS_USE_POLARSSL=1 -DLWS_POLARSSL_INCLUDE_DIRS=/usr/include -DLWS_POLARSSL_LIBRARIES=/usr/lib64/libmbedtls.so.9
This patch adds the cmake support and adapts [private-]libwebsockets.h but doesn't
modify the apis in ssl[-*].c yet.
Signed-off-by: Andy Green <andy@warmcat.com>
Most of ssl.c is under a #ifdef for client or server disabled...
let's get rid of it and have CMake just build the appropriate
files
Signed-off-by: Andy Green <andy@warmcat.com>
This makes a start on the LibWebSockets WebServer.
The app cmake build support and JSON config parsing are implemented and
the app can start, create the vhosts, listen and serve file:// mounts on
them.
Signed-off-by: Andy Green <andy@warmcat.com>
If you enable -DLWS_WITH_HTTP_PROXY=1 at cmake, the test server has a
new URI path http://localhost:7681/proxytest If you visit here, a client
connection to http://example.com:80 is spawned, and the results piped on
to your original connection.
Also with LWS_WITH_HTTP_PROXY enabled at cmake, lws wants to link to an
additional library, "libhubbub". This allows lws to do html rewriting on the
fly, adjusting proxied urls in a lightweight and fast way.
This gets the libuv stuff plumbed in and working.
Currently it's only workable for some service thread, and there
is an isolated valgrind problem left
==28425== 128 bytes in 1 blocks are definitely lost in loss record 3 of 3
==28425== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28425== by 0x4C2AB1E: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28425== by 0x58BBB27: maybe_resize (core.c:748)
==28425== by 0x58BBB27: uv__io_start (core.c:787)
==28425== by 0x58C1B80: uv__signal_loop_once_init (signal.c:225)
==28425== by 0x58C1B80: uv_signal_init (signal.c:260)
==28425== by 0x58BF7A6: uv_loop_init (loop.c:66)
==28425== by 0x4157F5: lws_uv_initloop (libuv.c:89)
==28425== by 0x405536: main (test-server-libuv.c:284)
libuv wants to sign off on all libuv 'handles' that will close, and
callback to do the close confirmation asynchronously. The wsi close function
is adapted when libuv is in use to work with libuv accordingly and exit the uv
loop the number of remaining wsi is zero.
Signed-off-by: Andy Green <andy.green@linaro.org>
This just lets you build lws 1.6 without pthreads if your OS / toolchain
makes that possible, in the case you don't build the test apps
(libwebsockets-test-server-pthreads needs it)
Signed-off-by: Andy Green <andy.green@linaro.org>
This adds support for multithreaded service to lws without adding any
threading or locking code in the library.
At context creation time you can request split the service part of the
context into n service domains, which are load-balanced so that the most
idle one gets the next listen socket accept.
There's a single listen socket on one port still.
User code may then spawn n threads doing n service loops / poll()s
simultaneously. Locking is only required (I think) in the existing
FD lock callbacks already handled by the pthreads server example,
and that locking takes place in user code. So the library remains
completely agnostic about the threading / locking scheme.
And by default, it's completely compatible with one service thread
so no changes are required by people uninterested in multithreaded
service.
However for people interested in extremely lightweight mass http[s]/
ws[s] service with minimum provisioning, the library can now do
everything out of the box.
To test it, just try
$ libwebsockets-test-server-pthreads -j 8
where -j controls the number of service threads
Signed-off-by: Andy Green <andy.green@linaro.org>
Sort the list of source files before passing them to the kernel-doc
script so that it always outputs the discovered functions and
structures in the same order.
This is the initial push of a fuzzing proxy we will use for testing lws.
Run libwebsockets-test-fuzxy and the test server if it's local.
Then run the test client with
http_proxy=localhost:8880 libwebsockets-test-client localhost (or whatever)
Right now he only fuzzes one thing but he is operational as a proxy.
If we enabled libev support, generate a test server variant that uses it.
Libev has sets its face against fixing its warnings and says -Werror is
"stupid". So we work around it for the problems their apis cause in
Travis.
Signed-off-by: Andy Green <andy.green@linaro.org>
It saves us ~4KB of lwsl_info / _debug etc strings.
The test app comes in at 114KB then, including 19KB of html, png and ico assets.
Signed-off-by: Andy Green <andy.green@linaro.org>
