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
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Setting m to 0 by default will prevent "error: ‘m’ may be used uninitialized in this function"
while compiling with the option -DLWS_WITH_LIBUV=ON.
With SMP as soon as we add the new sockfd to the fds table, in the
case we load-balanced the fd on to a different pt, service on it
becomes live immediately and concurrently. This can lead to the
unexpected situation that while we think we're still initing the
new wsi from our thread, it can have lived out its whole life
concurrently from another service thread.
Add a volatile flag to inform the owning pt that if it wants to
service the wsi during this init window, it must wait and retry
next time around the event loop.
On lwsws, incoming ws connections to the default vhost
are not rejected by the dummy protocol handler and not
really serviced either, leading to bots connecting to it to
get immortal, idle ws connections with no timeout (since it's an
established ws connection).
Rejecting these connections by default by adding a handler
for ESTABLISHED in the dummy handler will solve it nicely,
but it will break an unknown number of dumb. protocol-less
user implementations that rely on this behaviour by using
break; from their own ESTABLISHED handler and calling
through to the currently NOP dummy handler one.
Add support to assertively disable the default protocol
index used for subprotocol-less ws connections instead.
On h1, cgi stdout close doesn't prompt the http close, instead it
times out. Fix that so we also close on h1, and make the close
action itself on http timeout less drastic.
As it was, GnuTLS actually marks the close as a fatal TLS error.
We gradually filled up the free allocation, and they don't provide any
method to delete the oldest automatically. You literally have to sit
there deleting one artifact at a time (we create 7 per commit) using
their webui. I'm not going to do that.
While it's full, appveyor builds will just break.
So disable it.
RFC7692 states that control messages should not be compressed so there is no
need to inflate these messages.
There can be a bug if a control message is received while processing a
compressed message since lws relies on the RSV bit of the first message to
inflate the rx buffer or not.
Here we also check the opcode to only inflate a message if it is a data message.
Fixes: #1470
