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>
