21697b3210
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. |
||
|---|---|---|
| .. | ||
| README.md | ||
| ss-h1.c | ||
| ss-h2.c | ||
| ss-mqtt.c | ||
| ss-raw.c | ||
| ss-ws.c | ||
Lws Protocol bindings for Secure Streams
This directory contains the code wiring up normal lws protocols to Secure Streams.
The lws_protocols callback
This is the normal lws struct lws_protocols callback that handles events and traffic on the lws protocol being supported.
The various events and traffic are converted into calls using the Secure Streams api, and Secure Streams events.
The connect_munge helper
Different protocols have different semantics in the arguments to the client connect function, this protocol-specific helper is called to munge the connect_info struct to match the details of the protocol selected.
The ss->policy->aux string is used to hold protocol-specific information
passed in the from the policy, eg, the URL path or websockets subprotocol
name.
The (library-private) ss_pcols export
Each protocol binding exports two things to other parts of lws (they are not exported to user code)
-
a struct lws_protocols, including a pointer to the callback
-
a struct ss_pcols describing how secure_streams should use, including a pointer to the related connect_munge helper.
In ./lib/core-net/vhost.c, enabled protocols are added to vhost protcols lists so they may be used. And in ./lib/secure-streams/secure-streams.c, enabled struct ss_pcols are listed and checked for matches when the user creates a new Secure Stream.