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.
Add -Wextra (with -Wno-unused-parameter) to unix builds in addition to
-Wall -Werror.
This can successfully build everything in Sai without warnings / errors.
This causes the blocking dns lookup to treat EAI_NONAME as immediately
fatal, this is usually caused by an assertive NXDOMAIN from the DNS server
or similar.
Not being able to reach the server should continue to retry.
In order to make the problem visible, it reports the situation using
CLIENT_CONNECTION_ERROR, even though it is still inside the outer client
creation call.
For both ss and sspc, enforce at runtime that user code cannot call
lws_ss[pc]_destroy on a handle from a callback.
The error indicates the remedy (return DESTROY_ME) and asserts.
It's open to user state callback to respond to the DISCONNECT we issue on
the proxy link closure by escalating it to a DESTROY_ME... we have to deal
with that if it comes.
In sai, on Xenial (only...) noticed that the wsi is still bound to the ss
handle, and can reference it even after the ss has been destroyed on
ss-testsfail sometimes.
Leave the handle knowing its wsi and able to detach it later during close.
We added the neccessary return check on set_metadata which is good, but it
doesn't take into account that for LWA, we will normally use the multipart
stuff, that provides its own conflicting content-type.
Currently the lwa streamtype policy doesn't even provide ctype metadata
type, let's just comment it out.
User reports problems with the close / retry flow not happening if we don't
pass thru the nwsi close... it may be happening before the sid1 migration.
Just log it and don't end the handling before the passthru. Logging it
because there was a reason for the change to not passing it through...
Trying to use the opaque pointer in the handle to point to the conn isn't
going to work when we need it to point to the ss handle.
Move it to have its on place in the handle.
Currently the lws_cancel_service() api only manifests itself at lws level.
This adds a state LWSSSCS_EVENT_WAIT_CANCELLED that is broadcast to all
SS in the event loop getting the cancel service api call, and allows
SS-level user code to pick up handling events from other threads.
There's a new example minimal-secure-streams-threads which shows the
pattern for other threads to communicate with and trigger the event in the
lws service thread.
It's already the case that leaving off the "tls_trust_store" member of the
streamtype definition in the policy causes the streamtype to validate its
tls connections via the OS trust store, usually a bundle OpenSSL has been
configured to load at init automagically, but also literally the OS trust
store in windows case.
Add tests to confirm that.
Defer recording the ss metrics histogram until wsi close, so it has a
chance to collect all the tags that apply.
Defer dumping metrics until the FINALIZE phase of context destroy, so we
had a chance to get any metrics recorded.
This fixes the proxy rx flow by adding an lws_dsh helper to hide the
off-by-one in the "kind" array (kind 0 is reserved for tracking the
unallocated dsh blocks).
For testing, it adds a --blob option on minimal-secure-streams[-client]
which uses a streamtype "bulkproxflow" from here
https://warmcat.com/policy/minimal-proxy-v4.2-v2.json
"bulkproxflow": {
"endpoint": "warmcat.com",
"port": 443,
"protocol": "h1",
"http_method": "GET",
"http_url": "blob.bin",
"proxy_buflen": 32768,
"proxy_buflen_rxflow_on_above": 24576,
"proxy_buflen_rxflow_off_below": 8192,
"tls": true,
"retry": "default",
"tls_trust_store": "le_via_dst"
}
This downloads a 51MB blob of random data with the SHA256sum
ed5720c16830810e5829dfb9b66c96b2e24efc4f93aa5e38c7ff4150d31cfbbf
The minimal-secure-streams --blob example client delays the download by
50ms every 10KiB it sees to force rx flow usage at the proxy.
It downloads the whole thing and checks the SHA256 is as expected.
Logs about rxflow status are available at LLL_INFO log level.
On 32-bit Linux compilers, long int == int == 32-bit. So even atol() cannot
handle ints above 0x7fffffff and clips any it finds at that.
There's only one instance in policy-json.c, use atoll() cast to uint64_t
to allow values up to 64-bit INT_MAX even on 32-bit machines.
If the larger application is defining vhosts using lejp-conf JSON, it's
often more convenient to describe the vhost for ss server binding to
that.
If the server policy endpoint (usually used to describe the server
interface bind) begins with '!', take the remainder of the endpoint
string as the name of a preexisting vhost to bind ss server to at
creation-time.
