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

764 lines
20 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;
/* 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 +
(h->u.http.any ? 2 : 0) + 1)
h->info.rx(ss_to_userobj(h),
&q[pending_issue],
n - pending_issue -
h->u.http.boundary_len - 1 -
(h->u.http.any ? 2 : 0) /* crlf */,
(!h->u.http.som ? LWSSS_FLAG_SOM : 0) |
LWSSS_FLAG_EOM | LWSSS_FLAG_RELATED_END);
/*
* 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 +
(h->u.http.any ? 2 : 0))
h->info.rx(ss_to_userobj(h), &q[pending_issue],
n - pending_issue -
h->u.http.boundary_len -
(h->u.http.any ? 2 /* crlf */ : 0),
(!h->u.http.som ? LWSSS_FLAG_SOM : 0) |
LWSSS_FLAG_EOM);
}
/* Next message starts after this boundary */
pending_issue = n;
h->u.http.som = 0;
around:
n++;
}
if (pending_issue != n) {
h->info.rx(ss_to_userobj(h), &q[pending_issue], n - pending_issue,
(!h->u.http.som ? LWSSS_FLAG_SOM : 0));
h->u.http.any = 1;
h->u.http.som = 1;
}
return 0;
}
#endif
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)
{
int m;
for (m = 0; m < h->policy->metadata_count; m++) {
lws_ss_metadata_t *polmd;
/* has to have a header string listed */
if (!h->metadata[m].value)
continue;
polmd = lws_ss_policy_metadata_index(h->policy, m);
assert(polmd);
/* has to have a value */
if (polmd->value && ((uint8_t *)polmd->value)[0]) {
if (lws_add_http_header_by_name(wsi,
polmd->value,
h->metadata[m].value,
(int)h->metadata[m].length, pp, end))
return -1;
}
}
/*
* 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;
}
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)
{
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: 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;
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:
assert(h);
assert(h->policy);
lwsl_info("%s: h: %p, %s CLIENT_CONNECTION_ERROR: %s\n", __func__,
h, h->policy->streamtype, in ? (char *)in : "(null)");
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: 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
if (lws_ss_event_helper(h, LWSSSCS_UNREACHABLE))
/* h has been destroyed */
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
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
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: 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
lwsl_notice("a4\n");
if (lws_ss_backoff(h))
/* was destroyed */
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
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:
if (h->policy->u.http.fail_redirect)
lws_system_cpd_set(lws_get_context(wsi),
LWS_CPD_CAPTIVE_PORTAL);
/* don't follow it */
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
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);
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: h: %p, %s LWS_CALLBACK_CLOSED_CLIENT_HTTP\n",
__func__, h,
h->policy ? h->policy->streamtype : "no policy");
h->wsi = NULL;
//bad = status != 200;
//lws_cancel_service(lws_get_context(wsi)); /* abort poll wait */
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: 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
if (lws_ss_backoff(h))
break;
} else
ss: http: if not retrying move to idle state
2020-06-19 18:25:56 +01:00
h->seqstate = SSSEQ_IDLE;
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: 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
lws_ss_event_helper(h, LWSSSCS_DISCONNECTED);
/* may have been destroyed */
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:
status = lws_http_client_http_response(wsi);
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
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);
if (h->u.http.good_respcode)
lwsl_info("%s: Connected streamtype %s, %d\n", __func__,
h->policy->streamtype, status);
else
lwsl_warn("%s: Connected streamtype %s, BAD %d\n", __func__,
h->policy->streamtype, status);
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);
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
if (lws_ss_event_helper(h, LWSSSCS_CONNECTED))
/* was destroyed */
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
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
/*
* 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
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 */
if (h->u.http.boundary[0])
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:
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++) {
int o = 0, n;
if (!h->policy->u.http.blob_header[m])
continue;
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;
buflen = sizeof(buf) - o - 2;
n = lws_system_blob_get(
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
lws_system_get_blob(wsi->a.context, blob_idx[m], 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
buf + o, &buflen, 0);
if (n < 0)
return -1;
buf[o + buflen] = '\0';
lwsl_debug("%s: adding blob %d: %s\n", __func__, m, buf);
if (lws_add_http_header_by_name(wsi,
(uint8_t *)h->policy->u.http.blob_header[m],
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
buf, (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
(void)oin;
// if (*p != oin)
// lwsl_hexdump_notice(oin, lws_ptr_diff(*p, oin));
}
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)
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.boundary[0])
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: http: handle rx DESTROY_ME
2020-07-20 14:41:28 +01:00
m = h->info.rx(ss_to_userobj(h), (const uint8_t *)in, len, f);
if (m == LWSSSSRET_DESTROY_ME)
goto do_destroy_me;
if (m < 0)
ss: handle rx and tx return values properly You can disconnect the stream by returning -1 from tx(). You can give up your chance to send anything by returning 1 from tx(). Returning 0 sends `*len` amount of the provided buffer. Returning <0 from rx() also disconnects the stream.
2020-05-04 14:34:45 +01:00
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
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:
lwsl_debug("%s: LWS_CALLBACK_COMPLETED_CLIENT_HTTP\n", __func__);
if (h->hanging_som)
h->info.rx(ss_to_userobj(h), NULL, 0, LWSSS_FLAG_EOM);
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: 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
if (h->u.http.good_respcode) {
if (lws_ss_event_helper(h, LWSSSCS_QOS_ACK_REMOTE))
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
/* was destroyed */
ss-h1: close bound wsi when state handler requests ss destroy
2020-07-03 08:57:24 +01:00
return -1;
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
} else
if (lws_ss_event_helper(h, LWSSSCS_QOS_NACK_REMOTE))
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
/* was destroyed */
ss-h1: close bound wsi when state handler requests ss destroy
2020-07-03 08:57:24 +01:00
return -1;
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
//bad = status != 200;
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:
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_info("%s: wsi %p, par %p, HTTP_WRITEABLE\n", __func__,
// wsi, wsi->mux.parent_wsi);
if (!h || !h->info.tx) {
lwsl_notice("%s: no handle / tx %p\n", __func__, h);
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,
h->txn_resp_set ?
(h->txn_resp ? h->txn_resp : 200) :
HTTP_STATUS_NOT_FOUND,
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);
ss: rideshare: fix length can be wrong
2020-07-14 11:50:04 +01:00
buflen = lws_ptr_diff(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
buflen = lws_ptr_diff(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
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
switch(h->info.tx(ss_to_userobj(h), h->txord++, p, &buflen, &f)) {
case LWSSSSRET_DISCONNECT_ME:
lwsl_debug("%s: tx handler asked to close conn\n", __func__);
return -1; /* close connection */
case LWSSSSRET_DESTROY_ME:
ss: http: handle rx DESTROY_ME
2020-07-20 14:41:28 +01:00
do_destroy_me:
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
lws_set_opaque_user_data(wsi, NULL);
h->wsi = NULL;
lws_ss_destroy(&h);
return -1; /* close connection */
case 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
/* don't want to send anything */
lwsl_debug("%s: dont want to write\n", __func__);
return 0;
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
default:
break;
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);
if (lws_write(wsi, buf + LWS_PRE, lws_ptr_diff(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)
if (!(h->info.flags & LWSSSINFLAGS_ACCEPTED) &&
(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:
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) {
lws_ss_set_metadata(h, "method",
lws_hdr_simple_ptr(wsi,
WSI_TOKEN_HTTP_COLON_METHOD), m);
m = lws_hdr_total_length(wsi, WSI_TOKEN_HTTP_COLON_PATH);
lws_ss_set_metadata(h, "path",
lws_hdr_simple_ptr(wsi,
WSI_TOKEN_HTTP_COLON_PATH), m);
} else
#endif
{
m = lws_hdr_total_length(wsi, WSI_TOKEN_GET_URI);
if (m) {
lws_ss_set_metadata(h, "path",
lws_hdr_simple_ptr(wsi,
WSI_TOKEN_GET_URI), m);
lws_ss_set_metadata(h, "method", "GET", 3);
} else {
m = lws_hdr_total_length(wsi, WSI_TOKEN_POST_URI);
if (m) {
lws_ss_set_metadata(h, "path",
lws_hdr_simple_ptr(wsi,
WSI_TOKEN_POST_URI), m);
lws_ss_set_metadata(h, "method", "POST", 4);
}
}
}
}
if (lws_ss_event_helper(h, LWSSSCS_SERVER_TXN))
/* was destroyed */
return -1;
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: 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;
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