If you just want a "file" in multipart, don't care about the length or
anything else, then you don't need any params tables and associated
allocations.
lws has been able to proxy h2 or h1 inbound connections to an
h1 onward connection for a while now. It's simple to use just
build with LWS_WITH_HTTP_PROXY and make a mount where the origin
is the onward connection details. Unix sockets can also be
used as the onward connection.
This patch extends the support to be able to also do the same for
inbound h2 or h1 ws upgrades to an h1 ws onward connection as well.
This allows you to offer completely different services in a
common URL space, including ones that connect back by ws / wss.
The callback flow is a bit more disruptive than doing the iteration
directly in your function. This helps by passing a user void *
into the callback set as an lws_dll[2]_foreach_safe() arg.
Until 1.1.1b OpenSSL didn't mind we were setting AAD for AES GCM
using EVP_EncryptUpdate() for both encrypt and decrypt... but now
it noticed and the bug is fixed.
If you have multiple vhosts with client contexts enabled, under
OpenSSL each one brings in the system cert bundle.
On libwebsockets.org, there are many vhosts and the waste adds up
to about 9MB of heap.
This patch makes a sha256 from the client context configuration, and
if a suitable client context already exists on another vhost, bumps
a refcount and reuses the client context.
In the case client contexts are configured differently, a new one
is created (and is available for reuse as well).
We use POSIX dir scanning apis normally, but for windows, we require libuv
to do it for us.
Formalize that into a wrapper lws_dir() that hides the backend code.
Make it configurable, ON by default and forced on with lejp-conf that
depends on it.
lejp-conf isn't the only user that needs to generate human-readable
JSON parsing error stacks.
Build it in with lejp and introduce an error code -> string api
info.protocols works okay, but it has an annoying problem... you have to know
the type for each protocol's pss at the top level of the code, so you can set
the struct lws_protocols user_data size for it.
Lws already rewrites the protocol tables for a vhost in the case of runtime
protocol plugins... this adapts that already-existing code slightly to give
a new optional way to declare the protocol array.
Everything works as before by default, but now info.protocols may be NULL and
info.pprotocols defined instead (if that's also NULL, as it will be if you
just ignore it after memsetting to 0, then it continues to fall back to the
dummy protocol handler as before).
info.pprotocols is a NULL-termined array of pointers to lws_protocol
structs. This can be composed at the top level of your code without knowing
anything except the name of the externally-defined lws_protocol struct(s).
The minimal example http-server-dynamic is changed to use the new scheme as
an example.
Without this patch, the build will break with gcc 8.2 as bellow.
optee_os/lib/libwebsockets/libwebsockets/lib/core-net/network.c: In function ‘lws_socket_bind’:
optee_os/lib/libwebsockets/libwebsockets/lib/core-net/network.c:347:4: error: ‘memcpy’ forming offset [5, 16] is out of the bounds [0, 4] of object ‘sin’ with type ‘struct sockaddr_storage’ [-Werror=array-bounds]
memcpy(&sain, &sin, sizeof(sain));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/akirat/dev/otrp/aist-tb/optee_os/lib/libwebsockets/libwebsockets/lib/core-net/network.c:224:26: note: ‘sin’ declared here
struct sockaddr_storage sin;
^~~
cc1: all warnings being treated as errors
Signed-off-by: Akira Tsukamoto <akira.tsukamoto@gmail.com>
The cmake config on the build system actually decides the release build optimization policy.
On Fedora, it's -O2. On Ubuntu, it's -O3.
Anything given in CMakeLists.txt is overridden by the build system policy since it goes at
the end of the compiler commandline.
When you are building cross, the build system's opinion of your cross binary optimization
level is irrelevant, and at worst destructive. Some versions of gcc contain broken optimizations
that are applied only at -O3.
This patch removes any doomed attempt to set -O in CMakeLists.txt, which has
no effect since the build system policy is still added at the end, but
removes confusion; and adds code to all the cross build files to forcibly
override release optimization level to -O2, removing the build system's
opinion of how your cross build should look.
Until now lws only parses headers it knows at build-time from its
prebuilt lexical analyzer.
This adds an on-by-default cmake option and a couple of apis
to also store and query "custom", ie, unknown-to-lws headers.
A minimal example is also provided.
At the moment it only works on h1, h2 support needs improvements
to the hpack implementation.
Since it bloats ah memory usage compared to without it if custom
headers are present, the related code and ah footprint can be
disabled with the cmake option LWS_WITH_CUSTOM_HEADERS, but it's
on by default normally. ESP32 platform disables it.
https://github.com/warmcat/libwebsockets/pull/1499
This seen in the wild...
==20578== Invalid read of size 1
==20578== at 0x4D2E018: uv_poll_stop (poll.c:112)
==20578== by 0x48BC159: elops_io_uv (libuv.c:684)
==20578== by 0x4872F55: __remove_wsi_socket_from_fds (pollfd.c:326)
==20578== by 0x486EF1B: __lws_close_free_wsi (close.c:425)
==20578== by 0x486F3E2: lws_close_free_wsi (close.c:518)
==20578== by 0x487564C: lws_service_fd_tsi (service.c:1033)
==20578== by 0x48BAEA9: lws_io_cb (libuv.c:117)
==20578== by 0x4D3606F: uv__io_poll (linux-core.c:379)
==20578== by 0x4D27714: uv_run (core.c:361)
==20578== by 0x48BC347: elops_run_pt_uv (libuv.c:735)
==20578== by 0x4875746: lws_service (service.c:1080)
==20578== by 0x401A51: main (main.c:309)
==20578== Address 0x58 is not stack'd, malloc'd or (recently) free'd
