Add the ability to just build plugins into the main library.
They are already designed to have a pinhole export for when
they are used as dynamic lib plugins so their namespace
does not conflict.
Also prioritize LD_LIBRARY_PATH check for plugins first
Iterate through paths in LD_LIBRARY_PATH in order
Warn on failed plugins init but continue protocol init
This is a huge patch that should be a global NOP.
For unix type platforms it enables -Wconversion to issue warnings (-> error)
for all automatic casts that seem less than ideal but are normally concealed
by the toolchain.
This is things like passing an int to a size_t argument. Once enabled, I
went through all args on my default build (which build most things) and
tried to make the removed default cast explicit.
With that approach it neither change nor bloat the code, since it compiles
to whatever it was doing before, just with the casts made explicit... in a
few cases I changed some length args from int to size_t but largely left
the causes alone.
From now on, new code that is relying on less than ideal casting
will complain and nudge me to improve it by warnings.
This adds some new objects and helpers for keeping and logging
info on grouped allocations, a group is, eg, SS handles or client
wsis.
Allocated objects get a context-unique "tag" string intended to replace
%p / wsi pointers etc. Pointers quickly become confusing when
allocations are freed and reused, the tag string won't repeat
until you produce 2^64 objects in a context.
In addition the tag string documents the object group, with prefixes
like "wsi-" or "vh-" and contain object-specific additional
information like the vhost name, address / port or the role of the wsi.
At creation time the lws code can use a format string and args
to add whatever group-specific info makes sense, eg, a wsi bound
to a secure stream can also append the guid of the secure stream,
it's copied into the new object tag and so is still available
cleanly after the stream is destroyed if the wsi outlives it.
Move the common plugin scanning dir stuff to be based on lws_dir, which
already builds for windows. Previously this was done via dirent for unix
and libuv for windows.
Reduce the dl plat stuff to just wrap instantiation and destruction of
dynlibs, establish common code in lib/misc/dir.c for plugin scanning
itself.
Migrate the libuv windows dl stuff to windows-plugins.c, so that he's
available even if later libuv loop support becomes and event lib plugin.
Remove the existing api exports scheme for plugins, just export a const struct
now which has a fixed header type but then whatever you want afterwards depending
on the class / purpose of the plugin. Place a "class" string in the header so
there can be different kinds of plugins implying different types exported.
Make the plugin apis public and add support for filter by class string, and
per instantation / destruction callbacks so the subclassed header type can
do its thing for the plugin class. The user provides a linked-list base
for his class of plugins, so he can manage them completely separately and
in user code / user export types.
Rip out some last hangers-on from generic sessions / tables.
This is all aimed at making the plugins support general enough so it can
provide event lib plugins later.
Generic sessions has been overdue some love to align it with
the progress in the rest of lws.
1) Strict Content Security Policy
2) http2 compatibility
3) fixes and additions for use in a separate process via unix domain socket
4) work on ws and http proxying in lws
5) add minimal example
https://libwebsockets.org/pipermail/libwebsockets/2019-April/007937.html
thanks to Bruce Perens for noting it.
This doesn't change the intention or status of the CC0 files, they were
pure CC0 before (ie, public domain) and they are pure CC0 now. It just
gets rid of the (C) part at the top of the dedication which may be read
to be a bit contradictory since the purpose is to make it public domain.
This has no effect on user code or backward compatibility.
It moves the in-tree public api header libwebsockets.h from ./lib
to ./include, and introduces a dir ./include/libwebsockets/
The single public api header is split out into 31 sub-headers
in ./include/libwebsockets. ./include/libwebsockets.h contains
some core types and platform adaptation code, but the rest of it
is now 31 #include <libwebsockets/...>
At install time, /usr/[local/]include/libwebsockets.h is installed
as before, along now with the 31 sub-headers in ...include/libwebsockets/
There's no net effect on user code.
But the api header is now much easier to maintain and study, with 31
topic-based sub headers.
ESP32 module price is now within range of 8266 price.
ESP32 capability and OS support is hugely better than 8266,
we can support mbedtls tls, http/2 etc with ESP32.
I'm no longer testing on ESP8266... there's no more
user traffic... it's time to go.
This enables selected things from -Wextra, can't use -Wextra because it is
fussy enough to complain about unused params on functions... they are
there for a reason.
-Wsign-compare
-Wignored-qualifiers
not -Wimplicit-fallthrough=3 ... only on gcc 7
-Wtype-limits
-Wuninitialized
not -Wclobbered ... only on gcc 7ish
fix the warnings everywhere they were found.
- introduce lib/tls/mbedtls lib/tls/openssl
- move wrapper into lib/tls/mbedtls/wrapper
- introduce private helpers to hide backend
This patch doesn't replace or remove the wrapper, it moves it
to lib/tls/mbedtls/wrapper.
But it should be now that the ONLY functions directly consuming
wrapper apis are isolated in
- lib/tls/mbedtls/client.c (180 lines)
- lib/tls/mbedtls/server.c (317 lines)
- lib/tls/mbedtls/ssl.c (325 lines)
In particular there are no uses of openssl or mbedtls-related
constants outside of ./lib/tls any more.
HTTP/2 support is now able to serve the test server, complete with
websockets, from a single vhost.
- This works the same with both OpenSSL and mbedTLS.
- POST is now wired up and works (also for file upload).
- CGI is wired up and works.
- Redirect is adapted and works
- lwsws works.
- URI urldecode, sanitation and argument parsing wired up for :path
valgrind clean (aside from openssl-style false uninit data usage in mbedtls send occasionally)
h2spec reports:
$ h2spec -h 127.0.0.1 -p 7681 -t -k -o 1
...
145 tests, 145 passed, 0 skipped, 0 failed"
Incorporates:
- "https://github.com/warmcat/libwebsockets/pull/1039
Fixes issue with -Werror=unused-variable flag
- 2c843a1395
ssl: fix infinite loop on client cert verification failure
Signed-off-by: Petar Paradzik <petar.paradzik@sartura.hr>"
Caused and fixes Coverity 184887 - 184892
Thanks to Fabrice Gilot for reporting the problem that led to uncovering this.
Due to a misunderstanding of the return value of snprintf (it is not truncated according
to the max size passed in) in several places relying on snprintf to truncate the length
overflows are possible.
This patch wraps snprintf with a new lws_snprintf() which does truncate its length to allow
the buffer limiting scheme to work properly.
All users should update with these fixes.
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>
