I was under the impression extensions could be null, so heres a patch to fix this error in libwebsockets. Cheers!
Signed-off-by: Andrew Chambers <andrewchamberss@gmail.com>
--
Ken found over the internet with real delays, SSL_connect can
fail to work. This patch adapts his workaround to stay in the
connect state until we either run out of time for the connect
or succeed.
Signed-off-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Ken Atherton <katherton@echofirst.com>
Android toolchain needs an extra include if it's not to confuse
SHA-1 code probably with incorrect endian-ness from missing /bits/
Signed-off-by: Peter Hillier <peterhillier@yahoo.com>
Signed-off-by: Andy Green <andy@warmcat.com>
ssize_t is needed, but absent in Windows.
This patch typedefs it to an int in that case as recommended by Tobias.
Signed-off-by: Andy Green <andy@warmcat.com>
Signed-off-by: David Brooks <dave@bcs.co.nz>
Signed-off-by: Tobias Maier <tobias.maier@netplace.com>
Reported-by: Rich Gossweiler <rich.gossweiler@gmail.com>
Found an issue in libwebsockets - if a server sends a message within its "onopen" context then the message is getting swallowed and not passed to calling client (means LWS_CALLBACK_CLIENT_RECEIVE is never getting called).
I've fixed the bug - pls find attached patch.
Signed-off-by: Yonathan Yusim <yonathan@boxee.tv>
Signed-off-by: Andy Green <andy@warmcat.com>
The code to prevent memory leaks caused by reallocating a wsi->utf8_token
was also causing wsi->parser_state to not be updated, preventing the
handshake from completing.
This patch changes the logic to append to previous allocation which is
correct behaviour actually.
Signed-off-by: Nick Dowell <nick@nickdowell.com>
Signed-off-by: Andy Green <andy@warmcat.com>
This prevents a problem observed on Windows whereby a client that
disconnects before fully establishing the WebSocket would cause the
server to use 100% CPU since recv() would continually return -1 for that
socket.
Signed-off-by: Nick Dowell <nick@nickdowell.com>
Carlo wrote
''I'm interested to use the libwebsockets server (C based) with a Java
websocket client. I was able to implement a Java websocket client based
on JWebSocket library that works fine with the libwebsockets server, but
I was obliged to patch the libwebsockets server in order to reach my
goal. In particular I patched the handshake_00() function because
JWebSocket library uses hixie 76 version. The problem was that the
JWebSocket library sends only WSI_TOKEN_SWORIGIN token instead
WSI_TOKEN_ORIGIN token. For this reason the handshake_00 failed because
the token length of WSI_TOKEN_ORIGIN was 0. I have written a patch in
order to control if at least one of the two tokens (WSI_TOKEN_SWORIGIN
and WSI_TOKEN_ORIGIN) is defined. I have attached into the e-mail the
patch. Probably it can be written better, but in any case I think that
this problem should be fixed for client/server compatibility.''
I found a simpler approach which is convert WSORIGIN processing to
go into ORIGIN token at the earliest point, then everything else can
stay the same.
I also noticed we would leak on duplicated headers and fixed that.
Reported-by: Carlo PARATA <carlo.parata@st.com>
Signed-off-by: Andy Green <andy@warmcat.com>
Hi Andy,
First off, thanks for libwebsockets :-)
I've encountered a crash when a client connects to a libwebsockets server
but speicifies an unsupported protocol (Sec-WebSocket-Protocol).
handshake.c should probably be checking that wsi->protocol->name is not
null before doing a strcmp with it...
Attached is a patch for your consideration.
Cheers!
Nick
Signed-off-by: Nick Dowell <nick@nickdowell.com>
Josh realized that with new Chrome, because we don't support the type of
compression extension yet we returned a null extension header.
This patch fixes that by deferring issuing the extension header until we
find we have something to say.
tested OK on google-chrome 19.0.1081.2-129295
Reported-by: Josh Roberson <josh@asteriasgi.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
While the protocol specification gives example of the
human-readable message associated with a 101-code reply,
nowhere does it actually enforce it. Ws4py gevent middleware
is known to have a message other than "Switching Protocols".
This quietens the spew so all typical debug info now is coming from
the user code (mirror protocol in the sample server / client case).
Signed-off-by: Andy Green <andy@warmcat.com>
This patch unifies the code for per-connection user allocation, and allows
it to be allocated earlier, duiring HTTP service time. It's also OK to
attempt allocation multiple times, it will just return any existing
allocation.
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Andy,
According http://www.ietf.org/rfc/rfc2616.txt HTTP character sets are identified by case-insensitive tokens.
Please replase
if (strcmp(lws_tokens[n].token, wsi->name_buffer))
continue;
to
if (stricmp(lws_tokens[n].token, wsi->name_buffer))
continue;
Oleg
Also introduce strcasecmp definition for win32
Signed-off-by: Oleg Golosovskiy <ogolosovskiy@unison.com>
This patch gets deflate-stream working with x-google-mux.
It adds a clean veto system where are extension can veto the proposal
of any extension when opening a new connection. x-google-mux uses that
in its callback to defeat any use of deflate-stream on mux children.
However deflate stream is allowed on the parent connection and works
transparently now alongside x-google-mux.
Signed-off-by: Andy Green <andy@warmcat.com>
This establishes a pre-close extension check to allow an extension to
veto a close. x-google-mux then uses this to stop ch1 going down
(subchannel 1 is the original socket connection that turns into a mux
parent) if it has active mux children; it just marks ch1 as closed in
its conn struct in that case and returns 1 from the callback to veto.
Code is also added to take care of the case ch1 is 'closed', and the
last child is subsequently closed, it actively calls close on the mux
parent then.
Signed-off-by: Andy Green <andy@warmcat.com>
