We want to manage the proxy txcr, but at the moment the proxy doesn't pass
back information about if it's actually h1 or h2 it found across the internet.
Temporarily defeat txcr wait so we can support h1 until that's improved.
Some general debugging advice but also really clarify the official way of how to dump
what is going out and coming in directly from the tls tunnel, so you can see the
actual data unencrypted.
We don't actually check that it provided results... return diags and
that the interface is usable if it didn't.
Also explicitly check ifa_name for being NULL, since it seems some
platforms can do that even with an ifa_addr (thanks to Jed)
Add initial support for defining servers using Secure Streams
policy and api semantics.
Serving h1, h2 and ws should be functional, the new minimal
example shows a combined http + SS server with an incrementing
ws message shown in the browser over tls, in around 200 lines
of user code.
NOP out anything to do with plugins, they're not currently used.
Update the docs correspondingly.
You may use separate rx or tx handlers to neatly isolate different
rx or tx state handling, for example if the connection enters some
mode where you may send a variety of possibly large things, it can
be advantageous to have different code handling each of the
different things.
This allows you to change the rx, tx and / or state handlers to
different ones suitable for the user protocol state, if it's helpful.
With upcoming SS Server support, this has another use when SS
indicates that the underlying protocol upgraded, eg, http -> ws,
you may want to change the handlers for the different sort of
payloads expected after that, according to your user protocol.
Presently a vh is allocated per trust store at policy parsing-time, this
is no problem on a linux-class device or if you decide you need a dynamic
policy for functionality reasons.
However if you're in a constrained enough situation that the static policy
makes sense, in the case your trust stores do not have 100% duty cycle, ie,
are anyway always in use, the currently-unused vhosts and their x.509 stack
are sitting there taking up heap for no immediate benefit.
This patch modifies behaviour in ..._STATIC_POLICY_ONLY so that vhosts and
associated x.509 tls contexts are not instantiated until a secure stream using
them is created; they are refcounted, and when the last logical secure
stream using a vhost is destroyed, the vhost and its tls context is also
destroyed.
If another ss connection is created that wants to use the trust store, the
vhost and x.509 context is regenerated again as needed.
Currently the refcounting is by ss, it's also possible to move the refcounting
to be by connection. The choice is between the delay to generate the vh
being visisble at logical ss creation-time, or at connection-time. It's anyway
not preferable to have ss instantiated and taking up space with no associated
connection or connection attempt underway.
NB you will need to reprocess any static policies after this patch so they
conform to the trust_store changes.
Tighten up the logging at info and have a build summary and version info
at notice level like this
[2020/07/19 07:01:07:5563] N: LWS: 4.0.99-v4.0.0-232-gd602af468, loglevel 1031
[2020/07/19 07:01:07:5567] N: NET IPv6-absent H1 H2 WS MQTT SS-JSON-POL SSPROX ASYNC_DNS
Currently we always reserve a fakewsi per pt so events that don't have a related actual
wsi, like vhost-protocol-init or vhost cert init via protocol callback can make callbacks
that look reasonable to user protocol handler code expecting a valid wsi every time.
This patch splits out stuff that user callbacks often unconditionally expect to be in
a wsi, like context pointer, vhost pointer etc into a substructure, which is composed
into struct lws at the top of it. Internal references (struct lws is opaque, so there
are only internal references) are all updated to go via the substructre, the compiler
should make that a NOP.
Helpers are added when fakewsi is used and referenced.
If not PLAT_FREERTOS, we continue to provide a full fakewsi in the pt as before,
although the helpers improve consistency by zeroing down the substructure. There is
a huge amount of user code out there over the last 10 years that did not always have
the minimal examples to follow, some of it does some unexpected things.
If it is PLAT_FREERTOS, that is a newer thing in lws and users have the benefit of
being able to follow the minimal examples' approach. For PLAT_FREERTOS we don't
reserve the fakewsi in the pt any more, saving around 800 bytes. The helpers then
create a struct lws_a (the substructure) on the stack, zero it down (but it is only
like 4 pointers) and prepare it with whatever we know like the context.
Then we cast it to a struct lws * and use it in the user protocol handler call.
In this case, the remainder of the struct lws is undefined. However the amount of
old protocol handlers that might touch things outside of the substructure in
PLAT_FREERTOS is very limited compared to legacy lws user code and the saving is
significant on constrained devices.
User handlers should not be touching everything in a wsi every time anyway, there
are several cases where there is no valid wsi to do the call with. Dereference of
things outside the substructure should only happen when the callback reason shows
there is a valid wsi bound to the activity (as in all the minimal examples).
For some patterns of JSON we return to parse at the outermost level and
meet a situation path_match is 0. In some places we're looking at things
from perspective of path_match - 1... that does not seem to cause trouble on
x86_64 but can on aarch64, which is how it got noticed.
This logically protects those accesses by checking !!path_match.
The old esp32 -factory stuff along with the lws support doesn't have a
future in its old form. It has users but the ratio of effort to
contribution is really especially bad. I haven't updated it for more
than a year since esp-idf changes broke the original stuff.
Freertos plat is alive and well and getting a lot of new use, ESP-32 is
supported both there and by modern lws_drivers pieces, including in CI
on real hardware, any further effort will be invested in that direction
instead of more vendor api-specific code (outside of wrapper
implementation).
lws_drivers wraps any SDK apis in generic lws apis such that your code
just uses those, enabling it to become SDK / SoC / vendor independent.
Its first implementation is on esp-idf, the low and mid-level features
that were in the old -factory are already available using that and
new technologies like lws_struct and Secure Streams.
There's a good pattern that's encouraged by using lws_struct pieces, that
we have an lws_dll2 owner with an array of objects listed in it that exist
in an lwsac. And because it came from JSON, there is tending to be a
logical name for the objects.
This adds a typed helper and wrapper to scan the owner list looking for
a specific name (of a specified length, not NUL terminated) in a specific
member of the listed objects, which must be a NUL-terminated const char *.
Again this is a good pattern that's encouraged by use of lws_tokenize
to recover the name we're looking for.
So it leads to the helper that can cleanly search for a listed object of the
right name from an owner, and return the typed object pointer or NULL, from a
length-specified string.
