AG: unlike openssl, mbedtls does not load the system trust store.
So this change will make client tls operations that work OK on openssl fail on
mbedtls unless you provide the correct CA cert.
This allows lws to distinguish between untrusted CAs, hostname
mismatches, expired certificates.
NOTE: LCCSCF_ALLOW_SELFSIGNED actually allows for untrusted CAs, and
will also skip hostname verification. This is somewhat a limitiation of
the current lws verification process.
AG: improve error reporting up to the CLIENT_CONNECTION_ERROR argument
and add a note specific to mbedtls in the test client. Adapt the test
client to note the CA requirement if built with mbedTLS. Adapt the
minimal test clients to have the CAs available and use them if mbedTLS.
This replaces the existing, unreleased lws_set_timer(wsi, secs) with
lws_set_timer_usecs(wsi, usecs).
wsi with a timer waiting are added to a linked-list sorted by the
timer trigger time.
1) poll() timeout (ie, poll wait) is trimmed to the nearest ms of the
first waiting timer if the default poll wait is longer than the
interval until the first waiting timer.
The linked-list of waiting timers is checked every entry and exit
from poll()... if no timers waiting or none reached their time
this costs almost nothing.
2) libuv: the earliest hrtimer is checked after every IO, again this
is costing nothing if the list head is NULL. If the case there
are hrtimers on the list, it costs a getimeofday (a VDSO in linux)
and more only if any of the timers have fired.
In addition on entry to libuv idle, if there are any waiting hrtimers
on the list, a libuv timer is used to force a wake in case we stay
idle (the libuv timer has ms resolution).
3) libev: not implemented
4) libevent: not implemented
Warnings are logged in the api is used on an event backend without
support. Patches welcome to add support similarly to libuv.
This is just an internal mass change of LWS_NO_EXTENSIONS to
LWS_WITHOUT_EXTENSIONS to match the public name and eliminate
all instances of LWS_NO_EXTENSIONS.
Until now LWS_CALLBACK_CLIENT_CONNECTION_ERROR handling could only
take place on protocols[0].
This patch changes LWS_CALLBACK_CLIENT_CONNECTION_ERROR to be sent
to the protocol the client connection was bound to... if nothing
better that is still protocols[0], but if you created the client
connection using info.local_protocol_name, it will now be sent to
the bound protocol handler instead.
In the case you are creating a client connection, there may be
no relationship between the ws protocol you want to bind to at
the server, and the local protocol name you want the wsi to
bind to at the client.
This introduces a new client info struct member .local_protocol_name,
if it is NULL then all is as before, otherwise it binds the client
wsi to the named protocol early in the process, and .protocol is used
for the negotiation with the ws server.
This allows you to bind client wsi to local protocol handlers that
don't share the name of the ws protocol the connection will try
to negotiate.
Until now LWS_CALLBACK_CLOSED has served the same for
client and server connections. This introduces a new
LWS_CALLBACK_CLIENT_CLOSE which is sent on established
ws client connections, insread of LWS_CALLBACK_CLOSED.
LWS_CALLBACK_CLOSED continues to be sent when server
ws connections close.
Everything in lws outside esp32 was changed to use lws_snprintf() a while ago.
This fixes a couple of stragglers and removes the preprocessor mangling.
In the case that the connection cannot be established because the caller
is unauthorized, it's likely they have to do something to gain
authorization before retrying. This change introduces a new message that
can be checked for to understand more about why the connection has
failed to establish.
Closes#1200
If the server rejects the attempt to establish a connection by returning
a response status other than 101, then it will not include the
Sec-WebSocket-Accept header. We need to check for 101 status (and return
an appropriate error message) before looking for the accept header.
See #1200
This allows you to set a 404 handler URL on a vhost.
The necessary user code looks like...
info.error_document_404 = "/404.html";
... at vhost-creation time.
In the existing lws_return_http_status() api, if it sees
the vhost has an "error_document_404" path set and that
we are trying to report a 404, it changes the action
instead to a redirect to the error_document_404 path.
The redirect target is returned using 404 status code.
If the redirect target doesn't exist, then it falls back
to just reporting the simple canned 404.
