This provides very memory-efficient CBOR stream parsing
and writing.
The parser converts pieces of CBOR into callbacks that define
the structure and collate string and blobs into buffer chunks
for extensible and easy access.
It is fragementation-safe and does not need all the CBOR in
the same place at one time, chunks of CBOR are parsed and
discarded as provided.
It does not allocate and just needs a few hundred bytes of
stack for even huge CBOR objects. Huge strings and blobs
are handled without needing memory to hold them atomically.
Includes ./minimal-examples/api-tests/api-test-lecp that
unit tests it against 82 official example CBORs and
26 additional test vectors from COSE (just checking the CBOR
parsing).
The writing apis allow printf style semantics with a variety
of CBOR-aware %-formats. The apis write into a context that
manages output buffer usage, if the output buffer fills,
then the apis return with an AGAIN code that lets you issue
and reset the output buffer and repeat the api all to issue
more output. The subsequent calls can occur much later or
from a different function context, so this is perfect for
WRITEABLE-mediated output from the network parts of lws.
See ./READMEs/README.cbor-lecp.md
--test404 sends us instead to httpbin.org/status/404
--test404red goes to warmcat.com/noexist.html which is handled as a
redirect to a 404 page (served with a 200...), streamtype
allows redirects to be followed
--test404redref same as above but streamtype disallows redirect follow
These should all produce CONMON results for the first response, be it 404
or 302 and whether the 302 was followed or not, and whether the client
goes via the proxy or not.
The FREERTOS plat has its own h2 SETTINGS, but although they are used, they
get overridden with the lws default SETTINGS during pt init.
Let's not do that if someone else has already touched the context set.
Add a transient state that indicates that we are retrying an upstream link
before the sspc creation can proceed.
The state() ack paramemeter shows the number of ms we have been retrying.
This is only issued if proxy mode clients are having difficulty reaching
their proxy, and are retrying.
As a transient state it doesn't affect the ss overall state, which will not
have reached CREATING yet.
Let's improve the details returned in CLIENT_CONNECTION_ERROR in string so
we can get more clues about the problem. Create dynamic strings that
classify at what step the error happened, and add dynamic info like the
errno.
This adds an indication of dns disposition to the conmon results,
and for http, if it gets that far a protocol-specific indication
of http response code.
Add a way to confirm that the ss handle recovered from a ss wsi is still
valid, by walking the pt ss list and confirming it is on there before using
it with conmon.
If it isn't, it will assert.
Normally we suppress CCEs while still in the client connection loop time,
since we can return failure directly to the caller.
In sspc client case, defeat that, in order to have a convenient place to
put code that cares about ongoing proxy link connection failures.
Add 9 fault injection cases in SS creation flow, and 5 of those
instantiate in the minimal examples ctests. The other 4 relate
to static policy and server, I tested the server ones by hand.
These tests confirm the recent change to unpick create using
lws_ss_destroy.
The late_bail discrete unpick flow is missing some pieces compared
to lws_ss_destroy. Unify the creation fail flow to also use
lws_ss_destroy so everything in one place.
Make lws_ss_destroy() not issue any states if the creation flow
didn't get as far as issuing CREATING.
Normally when doing a Client Connection Error handling,
we can action any ss relationship straight away since
we are in a wsi callback without any ss-aware parents
in the call stack.
But in the specific case we're doing the initial onward
wsi connection part on behalf of a ss, in fact the call
stack does have earlier parents holding references on
the related ss.
For example
secstream_h1 (ss-h1.c:470) CCE
lws_inform_client_conn_fail (close.c:319) fails early
lws_client_connect_2_dnsreq (connect2.c:349)
lws_http_client_connect_via_info2 (connect.c:71)
lws_header_table_attach (parsers.c:291)
rops_client_bind_h1 (ops-h1.c:1001)
lws_client_connect_via_info (connect.c:429) start onward connect
_lws_ss_client_connect (secure-streams.c:859)
_lws_ss_request_tx (secure-streams.c:1577)
lws_ss_request_tx (secure-streams.c:1515) request tx
ss_cpd_state (captive-portal-detect.c:50)
lws_ss_event_helper (secure-streams.c:408)
lws_ss_create (secure-streams.c:1256) SS Create
Under these conditions, we can't action the DESTROY_ME that
is coming when the CCE exhausts the retries.
This patch adds a flag that is set during the SS's onward wsi
connection attempt and causes it to stash rather than action
the result code.
The result code is brought out from the stash when we return to
_lws_ss_client_connect level, and passed up in the SS flow until
it is actioned, cleanly aborting the ss create.
