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>
This also changes the wsi_children array to be indexed by subchannel - 2,
non-existent channels are NULL in there and highest_child_subchannel
is a highwater mark for the highest subchannel ever used. That way we
can immediately get the wsi for a subchannel at the cost of some extra
sparse skipping during management.
This also takes care of scanning for empty slots on allocation and
NULLing on close of subchannel instead of deletion.
Signed-off-by: Andy Green <andy@warmcat.com>
Accidentally included half-done MUX_REAL_CHILD_INDEX_OFFSET addition a couple
of patches back after late night hacking, this patch completes it.
This makes mux added channels start at channel index 2.
1 is reserved for original carrier channel, 0 for as-yet badly defined global mux commands
Signed-off-by: Andy Green <andy@warmcat.com>
This implements clean client and server close for mux child connections,
and deals with accounting for parent child lists.
The mux link can then survive constant connection bringup and teardown
found in the new test client.
Signed-off-by: Andy Green <andy@warmcat.com>
Zero length payloads aren't handled properly. This patch
should solve that.
Reported-by: Chee Wooi Saw <cheewooi@gtwholdings.com>
Signed-off-by: Andy Green <andy@warmcat.com>
Client does auto-service server's ping, but then it
fell through and issued it as payload. This fixes that
so there is no payload issued.
Reported-by: Chee Wooi Saw <cheewooi@gtwholdings.com>
Signed-off-by: Andy Green <andy@warmcat.com>
This is initial x-google-mux support. It's disabled by default
since it's very pre-alpha.
1) To enable it, reconfigure with --enable-x-google-mux
2) It conflicts with deflate-stream, use the -u switch on
the test client to disable deflate-stream
3) It deviates from the google standard by sending full
headers in the addchannel subcommand rather than just
changed ones from original connect
4) Quota is not implemented yet
5) Close of subchannel is not really implemented yet
6) Google opcode 0xf is changed to 0x7 to account for
v7 protocol changes to opcode layout
However despite those caveats, in fact it can run the
test client reliably over one socket (both dumb-increment
and lws-mirror-protocol), you can open a browser on the
same test server too and see the circles, etc.
Signed-off-by: Andy Green <andy@warmcat.com>
Mozilla implementationcan issue window of up to 15,
need to match it
Reported-by: Patrick McManus <pmcmanus@mozilla.com>
Signed-off-by: Andy Green <andy@warmcat.com>
