Mirrors/libwebsockets
1
0
Fork 0
mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-16 00:00:07 +01:00
Code Issues Releases Wiki Activity
libwebsockets/lib/secure-streams/protocols/ss-h1.c

1105 lines
28 KiB
C
Raw Normal View History

client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* libwebsockets - small server side websockets and web server implementation
*
* Copyright (C) 2019 - 2020 Andy Green <andy@warmcat.com>
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*
* This is the glue that wires up h1 to Secure Streams.
*/
#include <private-lib-core.h>
#if !defined(LWS_PLAT_FREERTOS) || defined(LWS_ROLE_H2)
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
#define LWS_WITH_SS_RIDESHARE
#endif
#if defined(LWS_WITH_SS_RIDESHARE)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
static int
ss_http_multipart_parser(lws_ss_handle_t *h, void *in, size_t len)
{
uint8_t *q = (uint8_t *)in;
int pending_issue = 0, n = 0;
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/* let's stick it in the boundary state machine first */
while (n < (int)len) {
if (h->u.http.boundary_seq != h->u.http.boundary_len) {
if (q[n] == h->u.http.boundary[h->u.http.boundary_seq])
h->u.http.boundary_seq++;
else {
h->u.http.boundary_seq = 0;
h->u.http.boundary_dashes = 0;
h->u.http.boundary_post = 0;
}
goto around;
}
/*
* We already matched the boundary string, now we're
* looking if there's a -- afterwards
*/
if (h->u.http.boundary_dashes < 2) {
if (q[n] == '-') {
h->u.http.boundary_dashes++;
goto around;
}
/* there was no final -- ... */
}
if (h->u.http.boundary_dashes == 2) {
/*
* It's an EOM boundary: issue pending + multipart EOP
*/
lwsl_debug("%s: seen EOP, n %d pi %d\n",
__func__, n, pending_issue);
/*
* It's possible we already started the decode before
* the end of the last packet. Then there is no
* remainder to send.
*/
if (n >= pending_issue + h->u.http.boundary_len +
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
(h->u.http.any ? 2 : 0) + 1) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->info.rx(ss_to_userobj(h),
&q[pending_issue],
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
(unsigned int)(n - pending_issue -
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->u.http.boundary_len - 1 -
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
(h->u.http.any ? 2 : 0) /* crlf */),
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
(!h->u.http.som ? LWSSS_FLAG_SOM : 0) |
LWSSS_FLAG_EOM | LWSSS_FLAG_RELATED_END);
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
h->u.http.eom = 1;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* Peer may not END_STREAM us
*/
return 0;
//return -1;
}
/* how about --boundaryCRLF */
if (h->u.http.boundary_post < 2) {
if ((!h->u.http.boundary_post && q[n] == '\x0d') ||
(h->u.http.boundary_post && q[n] == '\x0a')) {
h->u.http.boundary_post++;
goto around;
}
/* there was no final CRLF ... it's wrong */
return -1;
}
if (h->u.http.boundary_post != 2)
goto around;
/*
* We have a starting "--boundaryCRLF" or intermediate
* "CRLF--boundaryCRLF" boundary
*/
lwsl_debug("%s: b_post = 2 (pi %d)\n", __func__, pending_issue);
h->u.http.boundary_seq = 0;
h->u.http.boundary_post = 0;
if (n >= pending_issue && (h->u.http.any || !h->u.http.som)) {
/* Intermediate... do the EOM */
lwsl_debug("%s: seen interm EOP n %d pi %d\n", __func__,
n, pending_issue);
/*
* It's possible we already started the decode before
* the end of the last packet. Then there is no
* remainder to send.
*/
if (n >= pending_issue + h->u.http.boundary_len +
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
(h->u.http.any ? 2 : 0)) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->info.rx(ss_to_userobj(h), &q[pending_issue],
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
(unsigned int)(n - pending_issue -
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->u.http.boundary_len -
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
(h->u.http.any ? 2 /* crlf */ : 0)),
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
(!h->u.http.som ? LWSSS_FLAG_SOM : 0) |
LWSSS_FLAG_EOM);
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
h->u.http.eom = 1;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
/* Next message starts after this boundary */
pending_issue = n;
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
if (h->u.http.eom) {
/* reset only if we have sent eom */
h->u.http.som = 0;
h->u.http.eom = 0;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
around:
n++;
}
if (pending_issue != n) {
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
uint8_t oh = 0;
/*
* handle the first or last "--boundaryCRLF" case which is not captured in the
* previous loop, on the Bob downchannel (/directive)
*
* probably does not cover the case that one boundary term is separated in multipile
* one callbacks though never see such case
*/
if ((n >= h->u.http.boundary_len) &&
h->u.http.boundary_seq == h->u.http.boundary_len &&
h->u.http.boundary_post == 2) {
oh = 1;
}
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
h->info.rx(ss_to_userobj(h), &q[pending_issue],
ss: http: mime parsing with unusual section boundaries
2021-01-06 17:13:17 -08:00
(unsigned int)(oh ?
(n - pending_issue - h->u.http.boundary_len -
(h->u.http.any ? 2 : 0)) :
(n - pending_issue)),
(!h->u.http.som ? LWSSS_FLAG_SOM : 0) |
(oh && h->u.http.any ? LWSSS_FLAG_EOM : 0));
if (oh && h->u.http.any)
h->u.http.eom = 1;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->u.http.any = 1;
h->u.http.som = 1;
}
return 0;
}
#endif
ss: policy: response code mapping This adds a per-streamtype JSON mapping table in the policy. In addition to the previous flow, it lets you generate custom SS state notifications for specific http response codes, eg: "http_resp_map": [ { "530": 1530 }, { "531": 1531 } ], It's not recommended to overload the transport-layer response code with application layer responses. It's better to return a 200 and then in the application protocol inside http, explain what happened from the application perspective, usually with JSON. But this is designed to let you handle existing systems that do overload the transport layer response code. SS states for user use start at LWSSSCS_USER_BASE, which is 1000. You can do a basic test with minimal-secure-streams and --respmap flag, this will go to httpbin.org and get a 404, and the warmcat.com policy has the mapping for 404 -> LWSSSCS_USER_BASE (1000). Since the mapping emits states, these are serialized and handled like any other state in the proxy case. The policy2c example / tool is also updated to handle the additional mapping tables.
2020-09-15 09:11:06 +01:00
/*
* Returns 0, or the ss state resp maps on to
*/
static int
lws_ss_http_resp_to_state(lws_ss_handle_t *h, int resp)
{
const lws_ss_http_respmap_t *r = h->policy->u.http.respmap;
int n = h->policy->u.http.count_respmap;
while (n--)
if (resp == r->resp)
return r->state;
else
r++;
return 0; /* no hit */
}
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/*
* This converts any set metadata items into outgoing http headers
*/
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
static int
lws_apply_metadata(lws_ss_handle_t *h, struct lws *wsi, uint8_t *buf,
uint8_t **pp, uint8_t *end)
{
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
lws_ss_metadata_t *polmd = h->policy->metadata;
int m = 0;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
while (polmd) {
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/* has to have a non-empty header string */
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
if (polmd->value__may_own_heap &&
ss: skip null metadata
2020-11-17 11:59:24 +00:00
((uint8_t *)polmd->value__may_own_heap)[0] &&
h->metadata[m].value__may_own_heap) {
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
if (lws_add_http_header_by_name(wsi,
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
polmd->value__may_own_heap,
h->metadata[m].value__may_own_heap,
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
(int)h->metadata[m].length, pp, end))
return -1;
ss: handle nonzero content-length set by metadata correctly
2020-11-24 11:11:19 +00:00
/*
* Check for the case he's setting a non-zero
* content-length "via the backdoor" metadata-
* driven headers, and set the body_pending()
* state if so...
*/
if (!strncmp(polmd->value__may_own_heap,
"content-length", 14) &&
atoi(h->metadata[m].value__may_own_heap))
lws_client_http_body_pending(wsi, 1);
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
}
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
m++;
polmd = polmd->next;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
}
/*
* Content-length on POST / PUT if we have the length information
*/
if (h->policy->u.http.method && (
(!strcmp(h->policy->u.http.method, "POST") ||
!strcmp(h->policy->u.http.method, "PUT"))) &&
wsi->http.writeable_len) {
if (!(h->policy->flags &
LWSSSPOLF_HTTP_NO_CONTENT_LENGTH)) {
int n = lws_snprintf((char *)buf, 20, "%u",
(unsigned int)wsi->http.writeable_len);
if (lws_add_http_header_by_token(wsi,
WSI_TOKEN_HTTP_CONTENT_LENGTH,
buf, n, pp, end))
return -1;
}
lws_client_http_body_pending(wsi, 1);
}
return 0;
}
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/*
* Check if any metadata headers present in the server headers, and record
* them into the associated metadata item if so.
*/
static int
lws_extract_metadata(lws_ss_handle_t *h, struct lws *wsi)
{
lws_ss_metadata_t *polmd = h->policy->metadata, *omd;
int n, m = 0;
while (polmd) {
cleaning
2020-10-04 07:27:22 +01:00
if (polmd->value_is_http_token != LWS_HTTP_NO_KNOWN_HEADER) {
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/* it's a well-known header token */
n = lws_hdr_total_length(wsi, polmd->value_is_http_token);
if (n) {
const char *cp = lws_hdr_simple_ptr(wsi,
polmd->value_is_http_token);
ss: take care to free any metadata heap values before overwrite Break out the core ss_set_metadata action into a subfunction that takes the lws_ss_metadata_t, and is fixed to retire heap-based values before they go out of scope, and adapt the exported version to call through to that. Simplify extract_metadata() to reuse the subfunction as well, in both well-known and custom header cases.
2020-10-07 17:51:58 +01:00
omd = lws_ss_get_handle_metadata(h, polmd->name);
if (!omd)
return 1;
assert(!strcmp(omd->name, polmd->name));
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/*
* it's present on the wsi, we want to
* set the related metadata name to it then
*/
ss: add set_metadata that takes a heap copy and make ss-h1 use it Until now we set metadata value pointers into the onward wsi ah data area... that's OK until we get a situation the wsi has gone away before we have a chance to deliver the metadata over the proxy link. Add a variant lws_ss_alloc_set_metadata() that allocates space on the heap and takes a copy of the input metadata. Change ss-h1 to alloc copies of its metadata so we no longer race the wsi ah lifetime.
2021-03-14 10:44:41 +00:00
_lws_ss_alloc_set_metadata(omd, polmd->name, cp,
(unsigned int)n);
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
ss: take care to free any metadata heap values before overwrite Break out the core ss_set_metadata action into a subfunction that takes the lws_ss_metadata_t, and is fixed to retire heap-based values before they go out of scope, and adapt the exported version to call through to that. Simplify extract_metadata() to reuse the subfunction as well, in both well-known and custom header cases.
2020-10-07 17:51:58 +01:00
#if defined(LWS_WITH_SECURE_STREAMS_PROXY_API)
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/*
* ...and because we are doing it from parsing
* onward rx, we want to mark the metadata as
* needing passing to the client
*/
omd->pending_onward = 1;
#endif
}
}
#if defined(LWS_WITH_CUSTOM_HEADERS)
else
/* has to have a non-empty header string */
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
if (polmd->value__may_own_heap &&
((uint8_t *)polmd->value__may_own_heap)[0]) {
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
char *p;
/*
* Can it be a custom header?
*/
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
n = lws_hdr_custom_length(wsi, (const char *)
polmd->value__may_own_heap,
polmd->value_length);
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
if (n > 0) {
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
p = lws_malloc((unsigned int)n + 1, __func__);
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
if (!p)
return 1;
/* if needed, free any previous value */
if (polmd->value_on_lws_heap) {
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
lws_free(
polmd->value__may_own_heap);
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
polmd->value_on_lws_heap = 0;
}
/*
cleaning
2020-10-04 07:27:22 +01:00
* copy the named custom header value
* into the malloc'd buffer
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
*/
if (lws_hdr_custom_copy(wsi, p, n + 1,
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
(const char *)
polmd->value__may_own_heap,
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
polmd->value_length) < 0) {
lws_free(p);
return 1;
}
omd = lws_ss_get_handle_metadata(h,
polmd->name);
coverity: ss: handle NULL omd
2021-05-26 14:07:00 +01:00
if (omd) {
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
coverity: ss: handle NULL omd
2021-05-26 14:07:00 +01:00
_lws_ss_set_metadata(omd,
polmd->name, p, (size_t)n);
omd->value_on_lws_heap = 1;
ss: take care to free any metadata heap values before overwrite Break out the core ss_set_metadata action into a subfunction that takes the lws_ss_metadata_t, and is fixed to retire heap-based values before they go out of scope, and adapt the exported version to call through to that. Simplify extract_metadata() to reuse the subfunction as well, in both well-known and custom header cases.
2020-10-07 17:51:58 +01:00
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
#if defined(LWS_WITH_SECURE_STREAMS_PROXY_API)
coverity: ss: handle NULL omd
2021-05-26 14:07:00 +01:00
omd->pending_onward = 1;
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
#endif
coverity: ss: handle NULL omd
2021-05-26 14:07:00 +01:00
}
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
}
}
#endif
m++;
polmd = polmd->next;
}
return 0;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
static const uint8_t blob_idx[] = {
LWS_SYSBLOB_TYPE_AUTH,
LWS_SYSBLOB_TYPE_DEVICE_SERIAL,
LWS_SYSBLOB_TYPE_DEVICE_FW_VERSION,
LWS_SYSBLOB_TYPE_DEVICE_TYPE,
};
int
secstream_h1(struct lws *wsi, enum lws_callback_reasons reason, void *user,
void *in, size_t len)
{
ss: server: add foreach client cb api Server SS maintains a list of accepted client ss, add an api allowing iterating through the clients via a user callback.
2020-11-10 11:27:28 +00:00
#if defined(LWS_WITH_SERVER)
struct lws_context_per_thread *pt = &wsi->a.context->pt[(int)wsi->tsi];
#endif
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_ss_handle_t *h = (lws_ss_handle_t *)lws_get_opaque_user_data(wsi);
uint8_t buf[LWS_PRE + 1520], *p = &buf[LWS_PRE],
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
#if defined(LWS_WITH_SERVER)
*start = p,
#endif
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
*end = &buf[sizeof(buf) - 1];
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
lws_ss_state_return_t r;
ss: formalize user cb retcodes It's not safe to destroy objects inside a callback from a parent that still has references to the object. Formalize what the user code can indicate by its return code from the callback functions and provide the implementations at the parents. - LWSSSSRET_OK: no action, OK - LWSSSSRET_DISCONNECT_ME: disconnect the underlying connection - LWSSSSRET_DESTROY_ME: destroy the ss object - LWSSSSRET_TX_DONT_SEND: for tx, give up the tx opportunity since nothing to send
2020-06-01 07:33:37 +01:00
int f = 0, m, status;
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
char conceal_eom = 0;
http: add RFC7231 date and time helpers and retry-after handling Teach lws how to deal with date: and retry-after: Add quick selftest into apt-test-lws_tokenize Expand lws_retry_sul_schedule_retry_wsi() to check for retry_after and increase the backoff if a larger one found. Finally, change SS h1 protocol to handle 503 + retry-after: as a failure, and apply any increased backoff from retry-after automatically.
2020-09-17 12:43:31 +01:00
lws_usec_t inter;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
size_t buflen;
switch (reason) {
case LWS_CALLBACK_CLIENT_CONNECTION_ERROR:
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
if (!h) {
lwsl_err("%s: CCE with no ss handle %s\n", __func__, lws_wsi_tag(wsi));
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
break;
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
assert(h->policy);
ss: sspc: add conmon performance telemetry 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.
2021-03-31 13:20:34 +01:00
lws_conmon_ss_json(h);
lws_metrics There are a few build options that are trying to keep and report various statistics - DETAILED_LATENCY - SERVER_STATUS - WITH_STATS remove all those and establish a generic rplacement, lws_metrics. lws_metrics makes its stats available via an lws_system ops function pointer that the user code can set. Openmetrics export is supported, for, eg, prometheus scraping.
2021-01-06 15:08:22 +00:00
lws_metrics_caliper_report_hist(h->cal_txn, wsi);
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
lwsl_info("%s: %s CLIENT_CONNECTION_ERROR: %s\n", __func__,
h->lc.gutag, in ? (const char *)in : "none");
ss: formalize user cb retcodes It's not safe to destroy objects inside a callback from a parent that still has references to the object. Formalize what the user code can indicate by its return code from the callback functions and provide the implementations at the parents. - LWSSSSRET_OK: no action, OK - LWSSSSRET_DISCONNECT_ME: disconnect the underlying connection - LWSSSSRET_DESTROY_ME: destroy the ss object - LWSSSSRET_TX_DONT_SEND: for tx, give up the tx opportunity since nothing to send
2020-06-01 07:33:37 +01:00
/* already disconnected, no action for DISCONNECT_ME */
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
r = lws_ss_event_helper(h, LWSSSCS_UNREACHABLE);
if (r)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
ss: event_helper handles destroy requests itself Callbacks can ask the caller to, eg, destroy the ss handle now. But some callback returns are handled and produced inside other helper apis, eg lws_ss_backoff() may have to had fulfilled the callback request to destroy the ss... therefore it has to signal to its caller, and its callers have to check and exit their flow accordingly.
2020-07-04 21:16:49 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->wsi = NULL;
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
r = lws_ss_backoff(h);
if (r != LWSSSSRET_OK)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
captive portal Implement Captive Portal detection support in lws, with the actual detection happening in platform code hooked up by lws_system_ops_t. Add an implementation using Secure Streams as well, if the policy defines captive_portal_detect streamtype, a SS using that streamtype is used to probe if it's behind a captive portal.
2020-03-11 12:44:01 +00:00
case LWS_CALLBACK_CLIENT_HTTP_REDIRECT:
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
if (!h)
return -1;
captive portal Implement Captive Portal detection support in lws, with the actual detection happening in platform code hooked up by lws_system_ops_t. Add an implementation using Secure Streams as well, if the policy defines captive_portal_detect streamtype, a SS using that streamtype is used to probe if it's behind a captive portal.
2020-03-11 12:44:01 +00:00
if (h->policy->u.http.fail_redirect)
lws_system_cpd_set(lws_get_context(wsi),
LWS_CPD_CAPTIVE_PORTAL);
ss: policy: flag to allow respecting redirects
2020-07-31 11:12:54 +01:00
/* unless it's explicitly allowed, reject to follow it */
return !(h->policy->flags & LWSSSPOLF_ALLOW_REDIRECTS);
captive portal Implement Captive Portal detection support in lws, with the actual detection happening in platform code hooked up by lws_system_ops_t. Add an implementation using Secure Streams as well, if the policy defines captive_portal_detect streamtype, a SS using that streamtype is used to probe if it's behind a captive portal.
2020-03-11 12:44:01 +00:00
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
case LWS_CALLBACK_CLOSED_HTTP: /* server */
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case LWS_CALLBACK_CLOSED_CLIENT_HTTP:
if (!h)
break;
ss: add timeout
2020-06-30 16:42:37 +01:00
lws_sul_cancel(&h->sul_timeout);
lws_metrics There are a few build options that are trying to keep and report various statistics - DETAILED_LATENCY - SERVER_STATUS - WITH_STATS remove all those and establish a generic rplacement, lws_metrics. lws_metrics makes its stats available via an lws_system ops function pointer that the user code can set. Openmetrics export is supported, for, eg, prometheus scraping.
2021-01-06 15:08:22 +00:00
ss: sspc: add conmon performance telemetry 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.
2021-03-31 13:20:34 +01:00
lws_conmon_ss_json(h);
lws_metrics There are a few build options that are trying to keep and report various statistics - DETAILED_LATENCY - SERVER_STATUS - WITH_STATS remove all those and establish a generic rplacement, lws_metrics. lws_metrics makes its stats available via an lws_system ops function pointer that the user code can set. Openmetrics export is supported, for, eg, prometheus scraping.
2021-01-06 15:08:22 +00:00
lws_metrics_caliper_report_hist(h->cal_txn, wsi);
//lwsl_notice("%s: %s LWS_CALLBACK_CLOSED_CLIENT_HTTP\n",
// __func__, wsi->lc.gutag);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->wsi = NULL;
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
ss: server: add foreach client cb api Server SS maintains a list of accepted client ss, add an api allowing iterating through the clients via a user callback.
2020-11-10 11:27:28 +00:00
#if defined(LWS_WITH_SERVER)
lws_pt_lock(pt, __func__);
lws_dll2_remove(&h->cli_list);
lws_pt_unlock(pt);
#endif
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->policy && !(h->policy->flags & LWSSSPOLF_OPPORTUNISTIC) &&
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
#if defined(LWS_WITH_SERVER)
!(h->info.flags & LWSSSINFLAGS_ACCEPTED) && /* not server */
#endif
fakewsi: replace with smaller substructure Currently we always reserve a fakewsi per pt so events that don't have a related actual wsi, like vhost-protocol-init or vhost cert init via protocol callback can make callbacks that look reasonable to user protocol handler code expecting a valid wsi every time. This patch splits out stuff that user callbacks often unconditionally expect to be in a wsi, like context pointer, vhost pointer etc into a substructure, which is composed into struct lws at the top of it. Internal references (struct lws is opaque, so there are only internal references) are all updated to go via the substructre, the compiler should make that a NOP. Helpers are added when fakewsi is used and referenced. If not PLAT_FREERTOS, we continue to provide a full fakewsi in the pt as before, although the helpers improve consistency by zeroing down the substructure. There is a huge amount of user code out there over the last 10 years that did not always have the minimal examples to follow, some of it does some unexpected things. If it is PLAT_FREERTOS, that is a newer thing in lws and users have the benefit of being able to follow the minimal examples' approach. For PLAT_FREERTOS we don't reserve the fakewsi in the pt any more, saving around 800 bytes. The helpers then create a struct lws_a (the substructure) on the stack, zero it down (but it is only like 4 pointers) and prepare it with whatever we know like the context. Then we cast it to a struct lws * and use it in the user protocol handler call. In this case, the remainder of the struct lws is undefined. However the amount of old protocol handlers that might touch things outside of the substructure in PLAT_FREERTOS is very limited compared to legacy lws user code and the saving is significant on constrained devices. User handlers should not be touching everything in a wsi every time anyway, there are several cases where there is no valid wsi to do the call with. Dereference of things outside the substructure should only happen when the callback reason shows there is a valid wsi bound to the activity (as in all the minimal examples).
2020-07-19 08:33:46 +01:00
!h->txn_ok && !wsi->a.context->being_destroyed) {
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
r = lws_ss_backoff(h);
if (r != LWSSSSRET_OK)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
break;
ss: event_helper handles destroy requests itself Callbacks can ask the caller to, eg, destroy the ss handle now. But some callback returns are handled and produced inside other helper apis, eg lws_ss_backoff() may have to had fulfilled the callback request to destroy the ss... therefore it has to signal to its caller, and its callers have to check and exit their flow accordingly.
2020-07-04 21:16:49 +01:00
} else
ss: http: if not retrying move to idle state
2020-06-19 18:25:56 +01:00
h->seqstate = SSSEQ_IDLE;
ss: server mode fixes
2021-01-11 08:29:02 +00:00
if (h->ss_dangling_connected) {
/* already disconnected, no action for DISCONNECT_ME */
r = lws_ss_event_helper(h, LWSSSCS_DISCONNECTED);
if (r != LWSSSSRET_OK)
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
case LWS_CALLBACK_ESTABLISHED_CLIENT_HTTP:
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
if (!h)
return -1;
ss: sspc: add conmon performance telemetry 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.
2021-03-31 13:20:34 +01:00
lws_conmon_ss_json(h);
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
status = (int)lws_http_client_http_response(wsi);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lwsl_info("%s: LWS_CALLBACK_ESTABLISHED_CLIENT_HTTP: %d\n", __func__, status);
// if (!status)
/* it's just telling use we connected / joined the nwsi */
// break;
captive portal Implement Captive Portal detection support in lws, with the actual detection happening in platform code hooked up by lws_system_ops_t. Add an implementation using Secure Streams as well, if the policy defines captive_portal_detect streamtype, a SS using that streamtype is used to probe if it's behind a captive portal.
2020-03-11 12:44:01 +00:00
lws_metrics There are a few build options that are trying to keep and report various statistics - DETAILED_LATENCY - SERVER_STATUS - WITH_STATS remove all those and establish a generic rplacement, lws_metrics. lws_metrics makes its stats available via an lws_system ops function pointer that the user code can set. Openmetrics export is supported, for, eg, prometheus scraping.
2021-01-06 15:08:22 +00:00
#if defined(LWS_WITH_SYS_METRICS)
if (status) {
lws_snprintf((char *)buf, 10, "%d", status);
lws_metrics_tag_ss_add(h, "http_resp", (char *)buf);
}
#endif
ss: h1: also handle 429 same as 503
2020-12-07 18:53:00 +00:00
if (status == HTTP_STATUS_SERVICE_UNAVAILABLE /* 503 */ ||
status == 429 /* Too many requests */) {
http: add RFC7231 date and time helpers and retry-after handling Teach lws how to deal with date: and retry-after: Add quick selftest into apt-test-lws_tokenize Expand lws_retry_sul_schedule_retry_wsi() to check for retry_after and increase the backoff if a larger one found. Finally, change SS h1 protocol to handle 503 + retry-after: as a failure, and apply any increased backoff from retry-after automatically.
2020-09-17 12:43:31 +01:00
/*
* We understand this attempt failed, and that we should
* conceal this attempt. If there's a specified
* retry-after, we should use that if larger than our
* computed backoff
*/
inter = 0;
lws_http_check_retry_after(wsi, &inter);
r = _lws_ss_backoff(h, inter);
if (r != LWSSSSRET_OK)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
http: add RFC7231 date and time helpers and retry-after handling Teach lws how to deal with date: and retry-after: Add quick selftest into apt-test-lws_tokenize Expand lws_retry_sul_schedule_retry_wsi() to check for retry_after and increase the backoff if a larger one found. Finally, change SS h1 protocol to handle 503 + retry-after: as a failure, and apply any increased backoff from retry-after automatically.
2020-09-17 12:43:31 +01:00
return -1; /* end this stream */
}
captive portal Implement Captive Portal detection support in lws, with the actual detection happening in platform code hooked up by lws_system_ops_t. Add an implementation using Secure Streams as well, if the policy defines captive_portal_detect streamtype, a SS using that streamtype is used to probe if it's behind a captive portal.
2020-03-11 12:44:01 +00:00
if (h->policy->u.http.resp_expect)
h->u.http.good_respcode =
status == h->policy->u.http.resp_expect;
else
h->u.http.good_respcode = (status >= 200 && status < 300);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
// lwsl_err("%s: good resp %d %d\n", __func__, status, h->u.http.good_respcode);
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
if (lws_extract_metadata(h, wsi)) {
lwsl_info("%s: rx metadata extract failed\n", __func__);
return -1;
}
ss: policy: response code mapping This adds a per-streamtype JSON mapping table in the policy. In addition to the previous flow, it lets you generate custom SS state notifications for specific http response codes, eg: "http_resp_map": [ { "530": 1530 }, { "531": 1531 } ], It's not recommended to overload the transport-layer response code with application layer responses. It's better to return a 200 and then in the application protocol inside http, explain what happened from the application perspective, usually with JSON. But this is designed to let you handle existing systems that do overload the transport layer response code. SS states for user use start at LWSSSCS_USER_BASE, which is 1000. You can do a basic test with minimal-secure-streams and --respmap flag, this will go to httpbin.org and get a 404, and the warmcat.com policy has the mapping for 404 -> LWSSSCS_USER_BASE (1000). Since the mapping emits states, these are serialized and handled like any other state in the proxy case. The policy2c example / tool is also updated to handle the additional mapping tables.
2020-09-15 09:11:06 +01:00
if (status) {
/*
* Check and see if it's something from the response
* map, if so, generate the requested status. If we're
* the proxy onward connection, metadata has priority
* over state updates on the serialization, so the
* state callback will see the right metadata.
*/
int n = lws_ss_http_resp_to_state(h, status);
if (n) {
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
r = lws_ss_event_helper(h, (lws_ss_constate_t)n);
ss: policy: response code mapping This adds a per-streamtype JSON mapping table in the policy. In addition to the previous flow, it lets you generate custom SS state notifications for specific http response codes, eg: "http_resp_map": [ { "530": 1530 }, { "531": 1531 } ], It's not recommended to overload the transport-layer response code with application layer responses. It's better to return a 200 and then in the application protocol inside http, explain what happened from the application perspective, usually with JSON. But this is designed to let you handle existing systems that do overload the transport layer response code. SS states for user use start at LWSSSCS_USER_BASE, which is 1000. You can do a basic test with minimal-secure-streams and --respmap flag, this will go to httpbin.org and get a 404, and the warmcat.com policy has the mapping for 404 -> LWSSSCS_USER_BASE (1000). Since the mapping emits states, these are serialized and handled like any other state in the proxy case. The policy2c example / tool is also updated to handle the additional mapping tables.
2020-09-15 09:11:06 +01:00
if (r != LWSSSSRET_OK)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi,
ss: policy: response code mapping This adds a per-streamtype JSON mapping table in the policy. In addition to the previous flow, it lets you generate custom SS state notifications for specific http response codes, eg: "http_resp_map": [ { "530": 1530 }, { "531": 1531 } ], It's not recommended to overload the transport-layer response code with application layer responses. It's better to return a 200 and then in the application protocol inside http, explain what happened from the application perspective, usually with JSON. But this is designed to let you handle existing systems that do overload the transport layer response code. SS states for user use start at LWSSSCS_USER_BASE, which is 1000. You can do a basic test with minimal-secure-streams and --respmap flag, this will go to httpbin.org and get a 404, and the warmcat.com policy has the mapping for 404 -> LWSSSCS_USER_BASE (1000). Since the mapping emits states, these are serialized and handled like any other state in the proxy case. The policy2c example / tool is also updated to handle the additional mapping tables.
2020-09-15 09:11:06 +01:00
&h);
}
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->u.http.good_respcode)
lwsl_info("%s: Connected streamtype %s, %d\n", __func__,
h->policy->streamtype, status);
else
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
if (h->u.http.good_respcode)
lwsl_warn("%s: Connected streamtype %s, BAD %d\n",
__func__, h->policy->streamtype,
status);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->hanging_som = 0;
h->retry = 0;
h->seqstate = SSSEQ_CONNECTED;
sul: multiple timer domains Adapt the pt sul owner list to be an array, and define two different lists, one that acts like before and is the default for existing users, and another that has the ability to cooperate with systemwide suspend to restrict the interval spent suspended so that it will wake in time for the earliest thing on this wake-suspend sul list. Clean the api a bit and add lws_sul_cancel() that only needs the sul as the argument. Add a flag for client creation info to indicate that this client connection is important enough that, eg, validity checking it to detect silently dead connections should go on the wake-suspend sul list. That flag is exposed in secure streams policy so it can be added to a streamtype with "swake_validity": true Deprecate out the old vhost timer stuff that predates sul. Add a flag LWS_WITH_DEPRECATED_THINGS in cmake so users can get it back temporarily before it will be removed in a v4.2. Adapt all remaining in-tree users of it to use explicit suls.
2020-05-28 12:48:17 +01:00
lws_sul_cancel(&h->sul);
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
ss: enforce only valid state transitions The various stream transitions for direct ss, SSPC, smd, and different protocols are all handled in different code, let's stop hoping for the best and add a state transition validation function that is used everywhere we pass a state change to a user callback, and knows what is valid for the user state() callback to see next, given the last state it was shown. Let's assert if lws manages to violate that so we can find where the problem is and provide a stricter guarantee about what user state handler will see, no matter if ss or sspc or other cases. To facilitate that, move the states to start from 1, where 0 indicates the state unset.
2021-01-02 10:49:43 +00:00
if (h->prev_ss_state != LWSSSCS_CONNECTED) {
r = lws_ss_event_helper(h, LWSSSCS_CONNECTED);
if (r != LWSSSSRET_OK)
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* Since it's an http transaction we initiated... this is
* proof of connection validity
*/
lws_validity_confirmed(wsi);
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
#if defined(LWS_WITH_SS_RIDESHARE)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
eventfd: use eventfd_read to check existence since its what we use
2020-07-29 20:36:19 +01:00
/*
ss: multipart without processing Change the default to not process multipart mime at SS layer. If it's desired, then set "http_multipart_ss_in" true in the policy on the streamtype. To test, use lws-minimal-secure-streams-avs, which uses SS processing as it is. To check it without the processing, change #if 1 to #if 0 around the policy for "http_multipart_ss_in" in both places in avs.c, and also enable the hexdump in ss_avs_metadata_rx() also in avs.c, and observe the multipart framing is passed through unchanged.
2020-08-10 10:38:04 +01:00
* There are two ways we might want to deal with multipart,
* one is pass it through raw (although the user code needs
* a helping hand for learning the boundary), and the other
* is to deframe it and provide basically submessages in the
* different parts.
eventfd: use eventfd_read to check existence since its what we use
2020-07-29 20:36:19 +01:00
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (lws_hdr_copy(wsi, (char *)buf, sizeof(buf),
WSI_TOKEN_HTTP_CONTENT_TYPE) > 0 &&
/* multipart/form-data;
* boundary=----WebKitFormBoundarycc7YgAPEIHvgE9Bf */
(!strncmp((char *)buf, "multipart/form-data", 19) ||
!strncmp((char *)buf, "multipart/related", 17))) {
struct lws_tokenize ts;
lws_tokenize_elem e;
// puts((const char *)buf);
memset(&ts, 0, sizeof(ts));
ts.start = (char *)buf;
ts.len = strlen(ts.start);
ts.flags = LWS_TOKENIZE_F_RFC7230_DELIMS |
LWS_TOKENIZE_F_SLASH_NONTERM |
LWS_TOKENIZE_F_MINUS_NONTERM;
h->u.http.boundary[0] = '\0';
do {
e = lws_tokenize(&ts);
if (e == LWS_TOKZE_TOKEN_NAME_EQUALS &&
!strncmp(ts.token, "boundary", 8) &&
ts.token_len == 8) {
e = lws_tokenize(&ts);
if (e != LWS_TOKZE_TOKEN)
goto malformed;
h->u.http.boundary[0] = '\x0d';
h->u.http.boundary[1] = '\x0a';
h->u.http.boundary[2] = '-';
h->u.http.boundary[3] = '-';
lws_strnncpy(h->u.http.boundary + 4,
ts.token, ts.token_len,
sizeof(h->u.http.boundary) - 4);
ss: windows build adaptations Windows compiler finds various non-bug things to complain about when building with SS and other options, fix them up
2020-04-06 20:25:06 +01:00
h->u.http.boundary_len =
(uint8_t)(ts.token_len + 4);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->u.http.boundary_seq = 2;
h->u.http.boundary_dashes = 0;
}
} while (e > 0);
lwsl_info("%s: multipart boundary '%s' len %d\n", __func__,
h->u.http.boundary, h->u.http.boundary_len);
/* inform the ss that a related message group begins */
ss: multipart without processing Change the default to not process multipart mime at SS layer. If it's desired, then set "http_multipart_ss_in" true in the policy on the streamtype. To test, use lws-minimal-secure-streams-avs, which uses SS processing as it is. To check it without the processing, change #if 1 to #if 0 around the policy for "http_multipart_ss_in" in both places in avs.c, and also enable the hexdump in ss_avs_metadata_rx() also in avs.c, and observe the multipart framing is passed through unchanged.
2020-08-10 10:38:04 +01:00
if ((h->policy->flags & LWSSSPOLF_HTTP_MULTIPART_IN) &&
h->u.http.boundary[0])
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->info.rx(ss_to_userobj(h), NULL, 0,
LWSSS_FLAG_RELATED_START);
// lws_header_table_detach(wsi, 0);
}
break;
malformed:
lwsl_notice("%s: malformed multipart header\n", __func__);
return -1;
#else
break;
#endif
case LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER:
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
if (!h)
return -1;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->writeable_len)
wsi->http.writeable_len = h->writeable_len;
{
uint8_t **p = (uint8_t **)in, *end = (*p) + len,
*oin = *(uint8_t **)in;
/*
* blob-based headers
*/
for (m = 0; m < _LWSSS_HBI_COUNT; m++) {
coverity: 62494: check system blob supposed to be used in h1 at runtime
2020-08-18 12:45:21 +01:00
lws_system_blob_t *ab;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
int o = 0, n;
if (!h->policy->u.http.blob_header[m])
continue;
ss: auth: sigv4 Add SS pieces for Sigv4 auth support
2020-12-29 16:42:25 -08:00
/*
* To be backward compatible, default is system-wide LWA auth,
* and "http_auth_header" is for default LWA auth, current users do not
* need any change in their policy.
* If user wants different auth/token, need to specify the "use_auth"
* and will be handled after metadata headers are applied.
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (m == LWSSS_HBI_AUTH &&
h->policy->u.http.auth_preamble)
o = lws_snprintf((char *)buf, sizeof(buf), "%s",
h->policy->u.http.auth_preamble);
if (o > (int)sizeof(buf) - 2)
return -1;
coverity: 62494: check system blob supposed to be used in h1 at runtime
2020-08-18 12:45:21 +01:00
ab = lws_system_get_blob(wsi->a.context, blob_idx[m], 0);
if (!ab)
return -1;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
buflen = sizeof(buf) - (unsigned int)o - 2u;
coverity: 62494: check system blob supposed to be used in h1 at runtime
2020-08-18 12:45:21 +01:00
n = lws_system_blob_get(ab, buf + o, &buflen, 0);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (n < 0)
return -1;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
buf[(unsigned int)o + buflen] = '\0';
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lwsl_debug("%s: adding blob %d: %s\n", __func__, m, buf);
if (lws_add_http_header_by_name(wsi,
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
(uint8_t *)h->policy->u.http.blob_header[m],
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
buf, (int)((int)buflen + o), p, end))
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return -1;
}
/*
* metadata-based headers
*/
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
if (lws_apply_metadata(h, wsi, buf, p, end))
return -1;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
ss: auth: sigv4 Add SS pieces for Sigv4 auth support
2020-12-29 16:42:25 -08:00
#if defined(LWS_WITH_SECURE_STREAMS_AUTH_SIGV4)
if (h->policy->auth && h->policy->auth->type &&
!strcmp(h->policy->auth->type, "sigv4")) {
if (lws_ss_apply_sigv4(wsi, h, p, end))
return -1;
}
#endif
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
(void)oin;
ss: auth: sigv4 Add SS pieces for Sigv4 auth support
2020-12-29 16:42:25 -08:00
//if (*p != oin)
// lwsl_hexdump_notice(oin, lws_ptr_diff_size_t(*p, oin));
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
/*
* So when proxied, for POST we have to synthesize a CONNECTED
* state, so it can request a writeable and deliver the POST
* body
*/
if ((h->policy->protocol == LWSSSP_H1 ||
h->policy->protocol == LWSSSP_H2) &&
ss: http: synthesize CONNECTED for PUT as well as POST
2020-08-10 14:22:26 +01:00
h->being_serialized && (
!strcmp(h->policy->u.http.method, "PUT") ||
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
!strcmp(h->policy->u.http.method, "POST"))) {
ss: metrics: http: just report at wsi close 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.
2021-04-08 06:36:01 +01:00
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
r = lws_ss_event_helper(h, LWSSSCS_CONNECTED);
if (r)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
}
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
/* chunks of chunked content, with header removed */
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
case LWS_CALLBACK_HTTP_BODY:
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ:
lwsl_debug("%s: RECEIVE_CLIENT_HTTP_READ: read %d\n",
__func__, (int)len);
ss: allow NULL cbs Some streamtypes do not pass or receive payload meaningfully. Allow them to just leave their related cb NULL. Ditto for state, although I'm not sure how useful such a streamtype can be.
2020-06-01 07:17:48 +01:00
if (!h || !h->info.rx)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0;
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
#if defined(LWS_WITH_SS_RIDESHARE)
ss: multipart without processing Change the default to not process multipart mime at SS layer. If it's desired, then set "http_multipart_ss_in" true in the policy on the streamtype. To test, use lws-minimal-secure-streams-avs, which uses SS processing as it is. To check it without the processing, change #if 1 to #if 0 around the policy for "http_multipart_ss_in" in both places in avs.c, and also enable the hexdump in ss_avs_metadata_rx() also in avs.c, and observe the multipart framing is passed through unchanged.
2020-08-10 10:38:04 +01:00
if ((h->policy->flags & LWSSSPOLF_HTTP_MULTIPART_IN) &&
h->u.http.boundary[0])
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return ss_http_multipart_parser(h, in, len);
#endif
if (!h->subseq) {
f |= LWSSS_FLAG_SOM;
h->hanging_som = 1;
h->subseq = 1;
}
// lwsl_notice("%s: HTTP_READ: client side sent len %d fl 0x%x\n",
// __func__, (int)len, (int)f);
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
r = h->info.rx(ss_to_userobj(h), (const uint8_t *)in, len, f);
if (r != LWSSSSRET_OK)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0; /* don't passthru */
/* uninterpreted http content */
case LWS_CALLBACK_RECEIVE_CLIENT_HTTP:
{
char *px = (char *)buf + LWS_PRE; /* guarantees LWS_PRE */
int lenx = sizeof(buf) - LWS_PRE;
ss: static policy: dynamic vhost instantiation Presently a vh is allocated per trust store at policy parsing-time, this is no problem on a linux-class device or if you decide you need a dynamic policy for functionality reasons. However if you're in a constrained enough situation that the static policy makes sense, in the case your trust stores do not have 100% duty cycle, ie, are anyway always in use, the currently-unused vhosts and their x.509 stack are sitting there taking up heap for no immediate benefit. This patch modifies behaviour in ..._STATIC_POLICY_ONLY so that vhosts and associated x.509 tls contexts are not instantiated until a secure stream using them is created; they are refcounted, and when the last logical secure stream using a vhost is destroyed, the vhost and its tls context is also destroyed. If another ss connection is created that wants to use the trust store, the vhost and x.509 context is regenerated again as needed. Currently the refcounting is by ss, it's also possible to move the refcounting to be by connection. The choice is between the delay to generate the vh being visisble at logical ss creation-time, or at connection-time. It's anyway not preferable to have ss instantiated and taking up space with no associated connection or connection attempt underway. NB you will need to reprocess any static policies after this patch so they conform to the trust_store changes.
2020-07-20 07:28:28 +01:00
m = lws_http_client_read(wsi, &px, &lenx);
if (m < 0)
return m;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
lws_set_timeout(wsi, 99, 30);
return 0; /* don't passthru */
case LWS_CALLBACK_COMPLETED_CLIENT_HTTP:
lws_metrics There are a few build options that are trying to keep and report various statistics - DETAILED_LATENCY - SERVER_STATUS - WITH_STATS remove all those and establish a generic rplacement, lws_metrics. lws_metrics makes its stats available via an lws_system ops function pointer that the user code can set. Openmetrics export is supported, for, eg, prometheus scraping.
2021-01-06 15:08:22 +00:00
// lwsl_debug("%s: LWS_CALLBACK_COMPLETED_CLIENT_HTTP\n", __func__);
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
if (!h)
return -1;
ss-hx: make sure hanging_some handled once
2020-12-27 08:41:54 +00:00
if (h->hanging_som) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->info.rx(ss_to_userobj(h), NULL, 0, LWSSS_FLAG_EOM);
ss-hx: make sure hanging_some handled once
2020-12-27 08:41:54 +00:00
h->hanging_som = 0;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
wsi->http.writeable_len = h->writeable_len = 0;
ss: add timeout
2020-06-30 16:42:37 +01:00
lws_sul_cancel(&h->sul_timeout);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
ss-h1: close bound wsi when state handler requests ss destroy
2020-07-03 08:57:24 +01:00
h->txn_ok = 1;
ss: metrics: add result tag reflecting ss txn disposition For http ss, add a tag result=SS_ACK_REMOTE or SS_NACK_REMOTE
2021-03-26 10:20:47 -07:00
#if defined(LWS_WITH_SYS_METRICS)
lws_metrics_tag_ss_add(h, "result",
h->u.http.good_respcode ?
"SS_ACK_REMOTE" : "SS_NACK_REMOTE");
#endif
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
r = lws_ss_event_helper(h, h->u.http.good_respcode ?
LWSSSCS_QOS_ACK_REMOTE :
LWSSSCS_QOS_NACK_REMOTE);
if (r != LWSSSSRET_OK)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
ss: formalize user cb retcodes It's not safe to destroy objects inside a callback from a parent that still has references to the object. Formalize what the user code can indicate by its return code from the callback functions and provide the implementations at the parents. - LWSSSSRET_OK: no action, OK - LWSSSSRET_DISCONNECT_ME: disconnect the underlying connection - LWSSSSRET_DESTROY_ME: destroy the ss object - LWSSSSRET_TX_DONT_SEND: for tx, give up the tx opportunity since nothing to send
2020-06-01 07:33:37 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_cancel_service(lws_get_context(wsi)); /* abort poll wait */
break;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
case LWS_CALLBACK_HTTP_WRITEABLE:
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case LWS_CALLBACK_CLIENT_HTTP_WRITEABLE:
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
if (!h || !h->info.tx) {
ss: h1: log dereferences NULL
2021-06-22 15:47:07 +01:00
lwsl_notice("%s: no handle / tx\n", __func__);
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
return 0;
}
#if defined(LWS_WITH_SERVER)
if (h->txn_resp_pending) {
/*
* If we're going to start sending something, we need to
* to take care of the http response header for it first
*/
h->txn_resp_pending = 0;
if (lws_add_http_common_headers(wsi,
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
(unsigned int)(h->txn_resp_set ?
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
(h->txn_resp ? h->txn_resp : 200) :
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
HTTP_STATUS_NOT_FOUND),
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
NULL, h->wsi->http.writeable_len,
&p, end))
return 1;
/*
* metadata-based headers
*/
if (lws_apply_metadata(h, wsi, buf, &p, end))
return -1;
if (lws_finalize_write_http_header(wsi, start, &p, end))
return 1;
/* write the body separately */
lws_callback_on_writable(wsi);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
}
#endif
if (
#if defined(LWS_WITH_SERVER)
!(h->info.flags & LWSSSINFLAGS_ACCEPTED) && /* not accepted */
#endif
!h->rideshare)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->rideshare = h->policy;
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
#if defined(LWS_WITH_SS_RIDESHARE)
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
if (
#if defined(LWS_WITH_SERVER)
!(h->info.flags & LWSSSINFLAGS_ACCEPTED) && /* not accepted */
#endif
!h->inside_msg && h->rideshare->u.http.multipart_name)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_client_http_multipart(wsi,
h->rideshare->u.http.multipart_name,
h->rideshare->u.http.multipart_filename,
h->rideshare->u.http.multipart_content_type,
(char **)&p, (char *)end);
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
buflen = lws_ptr_diff_size_t(end, p);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->policy->u.http.multipart_name)
buflen -= 24; /* allow space for end of multipart */
ss: rideshare: fix length can be wrong
2020-07-14 11:50:04 +01:00
#else
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
buflen = lws_ptr_diff_size_t(end, p);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
#endif
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
r = h->info.tx(ss_to_userobj(h), h->txord++, p, &buflen, &f);
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
if (r == LWSSSSRET_TX_DONT_SEND)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0;
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
if (r < 0)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
// lwsl_notice("%s: WRITEABLE: user tx says len %d fl 0x%x\n",
// __func__, (int)buflen, (int)f);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
p += buflen;
if (f & LWSSS_FLAG_EOM) {
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
#if defined(LWS_WITH_SERVER)
if (!(h->info.flags & LWSSSINFLAGS_ACCEPTED)) {
#endif
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
conceal_eom = 1;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/* end of rideshares */
if (!h->rideshare->rideshare_streamtype) {
lws_client_http_body_pending(wsi, 0);
ss: rideshare fix for when h2 not available
2020-06-26 10:35:06 +01:00
#if defined(LWS_WITH_SS_RIDESHARE)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->rideshare->u.http.multipart_name)
lws_client_http_multipart(wsi, NULL, NULL, NULL,
(char **)&p, (char *)end);
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
conceal_eom = 0;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
#endif
ss: rideshare fix for when h2 not available
2020-06-26 10:35:06 +01:00
} else {
fakewsi: replace with smaller substructure Currently we always reserve a fakewsi per pt so events that don't have a related actual wsi, like vhost-protocol-init or vhost cert init via protocol callback can make callbacks that look reasonable to user protocol handler code expecting a valid wsi every time. This patch splits out stuff that user callbacks often unconditionally expect to be in a wsi, like context pointer, vhost pointer etc into a substructure, which is composed into struct lws at the top of it. Internal references (struct lws is opaque, so there are only internal references) are all updated to go via the substructre, the compiler should make that a NOP. Helpers are added when fakewsi is used and referenced. If not PLAT_FREERTOS, we continue to provide a full fakewsi in the pt as before, although the helpers improve consistency by zeroing down the substructure. There is a huge amount of user code out there over the last 10 years that did not always have the minimal examples to follow, some of it does some unexpected things. If it is PLAT_FREERTOS, that is a newer thing in lws and users have the benefit of being able to follow the minimal examples' approach. For PLAT_FREERTOS we don't reserve the fakewsi in the pt any more, saving around 800 bytes. The helpers then create a struct lws_a (the substructure) on the stack, zero it down (but it is only like 4 pointers) and prepare it with whatever we know like the context. Then we cast it to a struct lws * and use it in the user protocol handler call. In this case, the remainder of the struct lws is undefined. However the amount of old protocol handlers that might touch things outside of the substructure in PLAT_FREERTOS is very limited compared to legacy lws user code and the saving is significant on constrained devices. User handlers should not be touching everything in a wsi every time anyway, there are several cases where there is no valid wsi to do the call with. Dereference of things outside the substructure should only happen when the callback reason shows there is a valid wsi bound to the activity (as in all the minimal examples).
2020-07-19 08:33:46 +01:00
h->rideshare = lws_ss_policy_lookup(wsi->a.context,
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->rideshare->rideshare_streamtype);
lws_callback_on_writable(wsi);
}
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
#if defined(LWS_WITH_SERVER)
}
#endif
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->inside_msg = 0;
} else {
/* otherwise we can spin with zero length writes */
if (!f && !lws_ptr_diff(p, buf + LWS_PRE))
break;
h->inside_msg = 1;
lws_callback_on_writable(wsi);
}
lwsl_info("%s: lws_write %d %d\n", __func__,
lws_ptr_diff(p, buf + LWS_PRE), f);
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
if (lws_write(wsi, buf + LWS_PRE, lws_ptr_diff_size_t(p, buf + LWS_PRE),
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
(!conceal_eom && (f & LWSSS_FLAG_EOM)) ?
LWS_WRITE_HTTP_FINAL : LWS_WRITE_HTTP) !=
ss: make sure to use LWS_WRITE_HTTP_FINAL with SS EOM flag When most of ss-h2 was combined into ss-h1 during development, the h2 difference about needing HTTP_FINAL to signal h2 FIN flag was accidentally dropped. In many cases the peer can infer it, from, eg, content-length reached. But we need to replace explicitly doing it to cover all cases.
2020-05-11 15:08:52 +01:00
(int)lws_ptr_diff(p, buf + LWS_PRE)) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lwsl_err("%s: write failed\n", __func__);
return -1;
}
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
#if defined(LWS_WITH_SERVER)
lws_metrics There are a few build options that are trying to keep and report various statistics - DETAILED_LATENCY - SERVER_STATUS - WITH_STATS remove all those and establish a generic rplacement, lws_metrics. lws_metrics makes its stats available via an lws_system ops function pointer that the user code can set. Openmetrics export is supported, for, eg, prometheus scraping.
2021-01-06 15:08:22 +00:00
if ((h->info.flags & LWSSSINFLAGS_ACCEPTED) /* server */ &&
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
(f & LWSSS_FLAG_EOM) &&
lws_http_transaction_completed(wsi))
return -1;
#else
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_set_timeout(wsi, 0, 0);
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
#endif
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
#if defined(LWS_WITH_SERVER)
case LWS_CALLBACK_HTTP:
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
if (!h)
return -1;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
lwsl_notice("%s: LWS_CALLBACK_HTTP\n", __func__);
{
h->txn_resp_set = 0;
h->txn_resp_pending = 1;
h->writeable_len = 0;
#if defined(LWS_ROLE_H2)
m = lws_hdr_total_length(wsi, WSI_TOKEN_HTTP_COLON_METHOD);
if (m) {
ss: add set_metadata that takes a heap copy and make ss-h1 use it Until now we set metadata value pointers into the onward wsi ah data area... that's OK until we get a situation the wsi has gone away before we have a chance to deliver the metadata over the proxy link. Add a variant lws_ss_alloc_set_metadata() that allocates space on the heap and takes a copy of the input metadata. Change ss-h1 to alloc copies of its metadata so we no longer race the wsi ah lifetime.
2021-03-14 10:44:41 +00:00
if (lws_ss_alloc_set_metadata(h, "method",
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
lws_hdr_simple_ptr(wsi,
ss: force check all set_metadata returns lws_ss_set_metadata can fail... eg, due to transient OOM situation... if it does, caller must take appropriate action like disconnect and retry. So mark the api as requiring the result checking, and make sure all the examples do it.
2021-03-14 08:27:06 +00:00
WSI_TOKEN_HTTP_COLON_METHOD), (unsigned int)m))
return -1;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
m = lws_hdr_total_length(wsi, WSI_TOKEN_HTTP_COLON_PATH);
ss: h2: handle zero length COLON_PATH for metadata
2021-06-04 15:30:55 +01:00
if (m && lws_ss_alloc_set_metadata(h, "path",
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
lws_hdr_simple_ptr(wsi,
ss: force check all set_metadata returns lws_ss_set_metadata can fail... eg, due to transient OOM situation... if it does, caller must take appropriate action like disconnect and retry. So mark the api as requiring the result checking, and make sure all the examples do it.
2021-03-14 08:27:06 +00:00
WSI_TOKEN_HTTP_COLON_PATH), (unsigned int)m))
return -1;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
} else
#endif
{
m = lws_hdr_total_length(wsi, WSI_TOKEN_GET_URI);
if (m) {
ss: add set_metadata that takes a heap copy and make ss-h1 use it Until now we set metadata value pointers into the onward wsi ah data area... that's OK until we get a situation the wsi has gone away before we have a chance to deliver the metadata over the proxy link. Add a variant lws_ss_alloc_set_metadata() that allocates space on the heap and takes a copy of the input metadata. Change ss-h1 to alloc copies of its metadata so we no longer race the wsi ah lifetime.
2021-03-14 10:44:41 +00:00
if (lws_ss_alloc_set_metadata(h, "path",
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
lws_hdr_simple_ptr(wsi,
ss: force check all set_metadata returns lws_ss_set_metadata can fail... eg, due to transient OOM situation... if it does, caller must take appropriate action like disconnect and retry. So mark the api as requiring the result checking, and make sure all the examples do it.
2021-03-14 08:27:06 +00:00
WSI_TOKEN_GET_URI), (unsigned int)m))
return -1;
ss: add set_metadata that takes a heap copy and make ss-h1 use it Until now we set metadata value pointers into the onward wsi ah data area... that's OK until we get a situation the wsi has gone away before we have a chance to deliver the metadata over the proxy link. Add a variant lws_ss_alloc_set_metadata() that allocates space on the heap and takes a copy of the input metadata. Change ss-h1 to alloc copies of its metadata so we no longer race the wsi ah lifetime.
2021-03-14 10:44:41 +00:00
if (lws_ss_alloc_set_metadata(h, "method", "GET", 3))
ss: force check all set_metadata returns lws_ss_set_metadata can fail... eg, due to transient OOM situation... if it does, caller must take appropriate action like disconnect and retry. So mark the api as requiring the result checking, and make sure all the examples do it.
2021-03-14 08:27:06 +00:00
return -1;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
} else {
m = lws_hdr_total_length(wsi, WSI_TOKEN_POST_URI);
if (m) {
ss: add set_metadata that takes a heap copy and make ss-h1 use it Until now we set metadata value pointers into the onward wsi ah data area... that's OK until we get a situation the wsi has gone away before we have a chance to deliver the metadata over the proxy link. Add a variant lws_ss_alloc_set_metadata() that allocates space on the heap and takes a copy of the input metadata. Change ss-h1 to alloc copies of its metadata so we no longer race the wsi ah lifetime.
2021-03-14 10:44:41 +00:00
if (lws_ss_alloc_set_metadata(h, "path",
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
lws_hdr_simple_ptr(wsi,
ss: force check all set_metadata returns lws_ss_set_metadata can fail... eg, due to transient OOM situation... if it does, caller must take appropriate action like disconnect and retry. So mark the api as requiring the result checking, and make sure all the examples do it.
2021-03-14 08:27:06 +00:00
WSI_TOKEN_POST_URI), (unsigned int)m))
return -1;
ss: add set_metadata that takes a heap copy and make ss-h1 use it Until now we set metadata value pointers into the onward wsi ah data area... that's OK until we get a situation the wsi has gone away before we have a chance to deliver the metadata over the proxy link. Add a variant lws_ss_alloc_set_metadata() that allocates space on the heap and takes a copy of the input metadata. Change ss-h1 to alloc copies of its metadata so we no longer race the wsi ah lifetime.
2021-03-14 10:44:41 +00:00
if (lws_ss_alloc_set_metadata(h, "method", "POST", 4))
ss: force check all set_metadata returns lws_ss_set_metadata can fail... eg, due to transient OOM situation... if it does, caller must take appropriate action like disconnect and retry. So mark the api as requiring the result checking, and make sure all the examples do it.
2021-03-14 08:27:06 +00:00
return -1;
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
}
}
}
}
ss: server mode fixes
2021-01-11 08:29:02 +00:00
if (!h->ss_dangling_connected) {
lws_metrics There are a few build options that are trying to keep and report various statistics - DETAILED_LATENCY - SERVER_STATUS - WITH_STATS remove all those and establish a generic rplacement, lws_metrics. lws_metrics makes its stats available via an lws_system ops function pointer that the user code can set. Openmetrics export is supported, for, eg, prometheus scraping.
2021-01-06 15:08:22 +00:00
#if defined(LWS_WITH_SYS_METRICS)
/*
* If any hanging caliper measurement, dump it, and free any tags
*/
lws_metrics_caliper_report_hist(h->cal_txn, (struct lws *)NULL);
#endif
ss: server mode fixes
2021-01-11 08:29:02 +00:00
r = lws_ss_event_helper(h, LWSSSCS_CONNECTED);
if (r)
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
}
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
r = lws_ss_event_helper(h, LWSSSCS_SERVER_TXN);
if (r)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
return 0;
#endif
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
default:
break;
}
return lws_callback_http_dummy(wsi, reason, user, in, len);
}
const struct lws_protocols protocol_secstream_h1 = {
"lws-secstream-h1",
secstream_h1,
0,
0,
};
/*
* Munge connect info according to protocol-specific considerations... this
* usually means interpreting aux in a protocol-specific way and using the
* pieces at connection setup time, eg, http url pieces.
*
* len bytes of buf can be used for things with scope until after the actual
* connect.
*/
static int
secstream_connect_munge_h1(lws_ss_handle_t *h, char *buf, size_t len,
struct lws_client_connect_info *i,
union lws_ss_contemp *ct)
{
ss: allow url style endpoint addresses The endpoint field in streamtype policy may continue to just be the hostname, like "warmcat.com". But it's also possible now to be a url-formatted string, like, eg, "https://warmcat.com:444/mailman/listinfo" If so (ie, if it contains a : ) then the decoded elements may override if tls is enabled, the endpoint address, the port, and the url path. No ABI change.
2020-03-14 06:56:41 +00:00
const char *pbasis = h->policy->u.http.url;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
size_t used_in, used_out;
lws_strexp_t exp;
ss: allow url style endpoint addresses The endpoint field in streamtype policy may continue to just be the hostname, like "warmcat.com". But it's also possible now to be a url-formatted string, like, eg, "https://warmcat.com:444/mailman/listinfo" If so (ie, if it contains a : ) then the decoded elements may override if tls is enabled, the endpoint address, the port, and the url path. No ABI change.
2020-03-14 06:56:41 +00:00
/* i.path on entry is used to override the policy urlpath if not "" */
if (i->path[0])
pbasis = i->path;
if (!pbasis)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0;
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/* uncomment to force h1 */
// i->alpn = "http/1.1";
ss: http: allow rideshare to gate EOM When rideshare is in use, the scope of the EOM is the rideshare section.
2020-05-28 13:09:56 +01:00
#if defined(LWS_WITH_SS_RIDESHARE)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->policy->flags & LWSSSPOLF_HTTP_MULTIPART)
i->ssl_connection |= LCCSCF_HTTP_MULTIPART_MIME;
if (h->policy->flags & LWSSSPOLF_HTTP_X_WWW_FORM_URLENCODED)
i->ssl_connection |= LCCSCF_HTTP_X_WWW_FORM_URLENCODED;
#endif
/* protocol aux is the path part */
i->path = buf;
ss: http: make sure we dont duplicate leading path slash if already present
2020-12-15 17:53:38 -08:00
/* skip the unnessary '/' */
if (*pbasis == '/')
pbasis = pbasis + 1;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
buf[0] = '/';
lws_strexp_init(&exp, (void *)h, lws_ss_exp_cb_metadata, buf + 1, len - 1);
ss: allow url style endpoint addresses The endpoint field in streamtype policy may continue to just be the hostname, like "warmcat.com". But it's also possible now to be a url-formatted string, like, eg, "https://warmcat.com:444/mailman/listinfo" If so (ie, if it contains a : ) then the decoded elements may override if tls is enabled, the endpoint address, the port, and the url path. No ABI change.
2020-03-14 06:56:41 +00:00
if (lws_strexp_expand(&exp, pbasis, strlen(pbasis),
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
&used_in, &used_out) != LSTRX_DONE)
return 1;
return 0;
}
const struct ss_pcols ss_pcol_h1 = {
"h1",
"http/1.1",
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
&protocol_secstream_h1,
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
secstream_connect_munge_h1,
NULL
};
Reference in a new issue Copy permalink