You can disconnect the stream by returning -1 from tx(). You can
give up your chance to send anything by returning 1 from tx().
Returning 0 sends `*len` amount of the provided buffer.
Returning <0 from rx() also disconnects the stream.
GCC -fanalyzer did find a real issue (unchecked malloc return)
but it mainly reported things that weren't true due to what
was happening outside of the particular compilation unit that
it could see.
In some cases devices may be too constrained to handle JSON policies but still
want to use SS apis and methodology.
This introduces an off-by-default cmake option LWS_WITH_SECURE_STREAMS_STATIC_POLICY_ONLY,
if enabled the JSON parsing part is excluded and it's assumed the user code
provides its policy as hardcoded policy structs.
There are a few automatic things that look for streamtypes that may or
may not exist now
- captive_portal_detect
- fetch_policy
- api_amazon_com_auth
logging them as notice every startup is pretty intrusive, change to info.
For general OpenSSL case, we leave connection validity to system trust
store bundle to decide; even for mbedtls it may have been passed a
bundle externally and we don't want to have to list the x.509 stack
explicitly for a server we don't have any control over.
Instead of erroring out, allow the case no trust store is specified,
just use vhost[0] and let the system trust store decide if it likes
the server's cert or not.
No ABI change.
The endpoint field in streamtype policy may continue to just be the
hostname, like "warmcat.com".
But it's also possible now to be a url-formatted string, like, eg,
"https://warmcat.com:444/mailman/listinfo"
If so (ie, if it contains a : ) then the decoded elements may override
if tls is enabled, the endpoint address, the port, and the url path.
No ABI change.
Make the policy load apis public with an extra argument that says if you want the
JSON to overlay on an existing policy rather than replace it.
Teach the stream type parser stuff to realize it already has an entry for the
stream type and to modify that rather than create a second one, allowing overlays
to modify stream types.
Add --force-portal and --force-no-internet flags to minimal-secure-streams and
use the new policy overlay stuff to force the policy for captive portal detection
to feel that there is one or that there's no internet.
Implement Captive Portal detection support in lws, with the actual
detection happening in platform code hooked up by lws_system_ops_t.
Add an implementation using Secure Streams as well, if the policy
defines captive_portal_detect streamtype, a SS using that streamtype
is used to probe if it's behind a captive portal.
Secure Streams is an optional layer on top of lws that separates policy
like endpoint selection and tls cert validation into a device JSON
policy document.
Code that wants to open a client connection just specifies a streamtype name,
and no longer deals with details like the endpoint, the protocol (!) or anything
else other than payloads and optionally generic metadata; the JSON policy
contains all the details for each streamtype. h1, h2, ws and mqtt client
connections are supported.
Logical secure streams outlive any particular connection and supports "nailed-up"
connectivity regardless of underlying connection stability.
