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".
Dan Zhang needed to defeat the recv() with PEEK in order to get working
poll() emulation on 64-bit windows.
I cleaned up the style in that file and made a version of his workaround
(which was force recv result to 0). I can't test the result so it may
need more work.
Reported-by: Dan Zhang <emaildanzhang@gmail.com>
Signed-off-by: Andy Green <andy@warmcat.com>
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>
