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>
Server handshake reply might not come in one packet as pointed out by
Pavel Borzenkov. This replaces his fix with one directly in the packet
state machine.
Signed-off-by: Andy Green <andy@warmcat.com>
Since 'shift' has unsigned integer type,
the following code may lead to infinite cycle
and segfault:
while (shift >= 0) {
if (shift)
buf[0 - pre + n] =
((len >> shift) & 127) | 0x80;
else
buf[0 - pre + n] =
((len >> shift) & 127);
n++;
shift -= 7;
}
Change type to signed integer.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@auriga.com>
While performing handshake recv() is called only once.
It may return only part of the data and handshake
will fail. This patch modifies libwebsocket_service_fd()
to ensure that there is not data left in the socket.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@auriga.com>
For the IETF revision 00 send 'Upgrade: WebSocket' header
instead of 'Upgrade: websocket' as described in the IETF standard.
Some servers (for example, phpdaemon) are case-sensitive.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@auriga.com>
Patrick McManus from Mozilla pointed out that the spec requires a specific kind
of zlib compression, which is raw. You can select that by using a funny api in
zlib. Mozilla are correcting their compression to this, pywebsockets already did
it right in the first place, libwebsockets should now work OK with those.
Signed-off-by: Andy Green <andy@warmcat.com>
you have your makefiles set up to treat warnings as errors, and my gcc
4.4.5 (64 bit) compiler generates 3 warnings that need fixing:
(that sprintf() one is a real bug.. if ext_name contains formatting
characters you are looking at a potential segv).
Signed-off-by: Patrick McManus <mcmanus@ducksong.com>
Ago noticed that some Windows clients experience small packets
from the server being aggregated and set after a long delay
(200-300ms).
He found that TCP_NODELAY on the socket solved this, I tested it
and it didn't have any noticable bad effect, so I implemented it
for all sockets, client and server.
Thans Ago for debugging this and notifying the cause.
Reported-by: Ago Allikmaa <maxorator@gmail.com>
Signed-off-by: Andy Green <andy@warmcat.com>
Notice that the naming is changed, the notification to a server that it can write to
the client is now called LWS_CALLBACK_SERVER_WRITEABLE, and the notification to a client
that it can write to a server is LWS_CALLBACK_CLIENT_WRITEABLE.
Signed-off-by: Andy Green <andy@warmcat.com>
Extensions might be caching stuff that we should spill before a controlled close.
It's not allowed to send anything on the wire after the close request, so we need
to make the extensions spill just before.
Signed-off-by: Andy Green <andy@warmcat.com>
... this afternoon I was just doing a little
interoperability testing around close... in my test-server I added
libwebsocket_close_and_free_session(this, wsi, LWS_CLOSE_STATUS_NORMAL);
in order to generate a server driven close.. I hope that was the right
way to go about it. In any event, in generated an invalid websocket
frame - I think you want this patch, or something like it:
Signed-off-by: \"Pat McManus @Mozilla\" <mcmanus@ducksong.com>
This goes through the extentsions the client requested, selects the ones
that we support at the server, and then further calls back to the appropriate
protocol callback in user code to check it's OK to actually use that
extension in this context. If it is (callback unhandled == it is) then
it's added to the list of extensions sent back to the client.
Accepted extensions are also added to the connection's active extension
list and the private "user" memory allocation for the extension context is
done and bound to the connection.
Signed-off-by: Andy Green <andy@warmcat.com>
