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.
The attribute indicating that a wsi belongs to an SS object also must be
migrated when we split out the original transaction wsi into a new nwsi, if we're
not going to lose track of its affiliation.
Likewise if the affiliated SS object points to the original wsi, we have to
migrate his pointer when we migrate the wsi.
Taking care of this book-keeping is necessary to get correct behaviours at
close-time.
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.
These two headers managed to avoid the global switch from
LGPL2.1 -> MIT back in the day, correct them to be aligned
with the rest of lws' own license, ie, MIT.
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.
If facing a captive portal, we may seem to get a tcp level connection okay
but find that communication is silently dropped, leading to us timing out
in LRS_WAITING_SERVER_REPLY.
If so, we need to handle it as a connection fail in order to satisfy at
least Captive Portal detection.
We have access to a simplified report of the problem name for tls
validation inside the validation cb, let's bring it out and
use it for OpenSSL CCE reporting.
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.
Before this commit, line 84 read 'u' before it had a value, on 1st for-loop iteration. See comment on line 84 below:
82 for (n = 0; n < 8; n++) {
83 ctx->gpio->set(ctx->clk, inv);
84 u = (u << 1) | !!ctx->gpio->read(ctx->miso); /* <-- u is used uninitialized here */
85 ctx->gpio->set(ctx->mosi, !!(u & 0x80));
86 ctx->gpio->set(ctx->clk, !inv);
87 }
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.
