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.
This extends threadpool slightly so it can bind enqueued tasks to a
secure streams handle as well as a straight wsi.
Either the .wsi must be set as before, or the .ss handle if you are
using secure streams, when enqueuing a task on the taskpool.
A couple of other helpers get ss-aware wrappers if LWS_WITH_SECURE_STREAMS
Although threadpool was originally designed for server (gitohashi)
actually it's also fine working with client wsi / Secure Streams,
if you have a situation a client connection is associated with heavy
processing.
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.
We worked fine while an earlier typo meant this was never getting past the
preprocessor... when it did, it exposes that the signal handler type was
never implemented. Just remove for glib.
Process HTTP headers related to content length for ws connections
and make 1 callback before continuing to the ws upgrade code.
This gives one last opportunity to ws protocols to inspect server reply
before the ws upgrade code discard it. ie: download reply body in case
of any other response code than 101.
This leads to problems at the moment with sticky mux.requested_POLLOUT
causing writeable to not be sent.
Remove it and always set writeable on parents for now.
When lws_write as many bytes as user can until function returns not all sent,
the next user`s lws_write call will write wrong frame to the other end. This
will cause connection be close by the other side.
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.
Adds client support for MQTT QoS0 and QoS1, compatible with AWS IoT
Supports stream binding where independent client connections to the
same endpoint can mux on a single tcp + tls connection with topic
routing managed internally.
Continue with lws_struct, add sqlite support for one
level of lws_dll2_t lists of structs serialization and
deserialization, plus the matching api-test.
Headers related to ws or h2 are now elided if the ws or h2 role
is not enabled for build. In addition, a new build-time option
LWS_WITH_HTTP_UNCOMMON_HEADERS on by default allows removal of
less-common http headers to shrink the parser footprint.
Minilex is adapted to produce 8 different versions of the lex
table, chosen at build-time according to which headers are
included in the build.
If you don't need the unusual headers, or aren't using h2 or ws,
this chops down the size of the ah and the rodata needed to hold
the parsing table from 87 strings / pointers to 49, and the
parsing table from 1177 to 696 bytes.
Surprisingly -fdata-sections -ffunction-sections does not remove any string literals and __func__
implicit .rodata generated by the removed function's compilation.
That means potentially considerable deadweight is in the image even if the function is removed
at linktime.
The vfork optimized spawn, stdxxx and terminal handling in the cgi
implementation is quite mature and sophisticated, and useful for
other things unrelated to cgi. Break it out into its own public
api under LWS_WITH_SPAWN, off by default.
Expand it so the parent wsi is optional, and the role and protocol
bindings for stdxxx pipes can be set. Allow optional sul timeout
and external lws_dll2 owner for extant children.
Remove inline style from minimal http-server-cgi
