My Browsers send as Subprotocols e.g. chat, superchat, mySubprotocol (with spaces after the ,). Libwebsockets now checked if ' mySubprotocol' was equal to 'mySubprotocol' which failed. With this fix the leading space is ignored and uses 'mySubprotocol' for comparision.
The `listen` call can fail with EADDRINUSE after bind() succeeds, for
example because another process called listen on that port in the
meantime, or under some circumstances with IPv6-mapped-IPv4. This was
causing EINVAL on accept, with an infinite loop in case of libuv.
A reproducible example was to run nc -l -p 5555 ( OpenBSD netcat (Debian
patchlevel 1)) before starting test-server
Signed-off-by: Denis Osvald <denis.osvald@sartura.hr>
Lws maintains a linked-list of wsi that are on the same vhost protocol...
it walks it to perform ..._all_protocol() type apis.
Client connections also participate in this list, but in the case the
selected protocol is not given during negotation (a legal case where
the server default protocol is selected) we missed adding the new
ws negotiated client wsi to the list.
This patch makes sure we add the wsi to the vhost protocols[0] list
in that case.
https://github.com/warmcat/libwebsockets/issues/716
https://github.com/warmcat/libwebsockets/issues/706
This fixes a problem where the check for the existing pw was
skipped when a logged-in user is changing his password.
It's not good but because the user has to be logged in, it only affected
the situation someone changes his password on his logged in session.
From linux ipv6(7) manual (section `Note`):
SOL_IP, SOL_IPV6, SOL_ICMPV6 and other SOL_* socket options are
nonportable variants of IPPROTO_*. See also ip(7).
Ref: http://man7.org/linux/man-pages/man7/ipv6.7.html
Some people are calling service with zero timeout, taking care of
not busywaiting by some other external arrangements.
Adapt the forced service signalling to survive this.
Lws cares about trailing \n on a lot of these tests now. Make it check it still cares on one and remove
the trailing \n on the others.
There's 2 changes in the results about /..//?, it seems to apply / to uri arg 1. But it doesn't seem
to make a problem so just adapt the results for now.
