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.
This provides a way to get ahold of LWS_WITH_CONMON telemetry from Secure
Streams, it works the same with direct onward connections or via the proxy.
You can mark streamtypes with a "perf": true policy attribute... this
causes the onward connections on those streamtypes to collect information
about the connection performance, and the unsorted DNS results.
Streams with that policy attribute receive extra data in their rx callback,
with the LWSSS_FLAG_PERF_JSON flag set on it, containing JSON describing the
performance of the onward connection taken from CONMON data, in a JSON
representation. Streams without the "perf" attribute set never receive
this extra rx.
The received JSON is based on the CONMON struct info and looks like
{"peer":"46.105.127.147","dns_us":596,"sockconn_us":31382,"tls_us":28180,"txn_resp_us:23015,"dns":["2001:41d0:2:ee93::1","46.105.127.147"]}
A new minimal example minimal-secure-streams-perf is added that collects
this data on an HTTP GET from warmcat.com, and is built with a -client
version as well if LWS_WITH_SECURE_STREAMS_PROXY_API is set, that operates
via the ss proxy and produces the same result at the client.
Setting the CONNECTED state only when SUBACK is received if the stream has
defined a subscription topic. This is to avoid SS from sending out SUBSCRIBE
right after CONNACK, even when the connection is not valid.
These functions can return 0 code but still store NULL in result, if no matching group or username found.
Also the buffer of 64 size could be too small to store all string fields in result.
We basically hear about HUP out-of-band with respect to
pending rx... now we mark the wsi as "unusable" once we
see the HUP - the connection has ended.
This means we have to differentiate between the wsi
being unusable for new things now, like replying, and
what it has already sent still being servicible and
pending.
This was commented during the metrics patch for some reason...
commenting it breaks UDS -> web serving proxying.
Uncomment it and see what the other problem is..
Improve how we report what happened with http_proxy... if
we can't recognize the response as http/1.0 or http/1.1
do a CCE with "http_proxy fail", or if we did get valid h1
response but no 200 response code, do a CCE with
"http_proxy -> xxx" where xxx is the decimal representation
of the response code, eg, "http_proxy -> 407"
This provides a build option LWS_WITH_CONMON that lets user code recover
detailed connection stats on client connections with the LCCSCF_CONMON
flag.
In addition to latencies for dns, socket connection, tls and first protocol
response where possible, it also provides the user code an unfiltered list
of DNS responses that the client received, and the peer it actually
succeded to connect to.
Otherwise sai is sometimes failing to get the correct process exit code
spawn: use WEXITSTATUS macro
On openbsd at least, the process retcode isn't in the low 8 bits, but must
be recovered using the official macro.
