[Libwebsockets] Deflate Frame Extension Question

"Andy Green (林安廸)" andy at warmcat.com
Wed Feb 13 04:42:04 CET 2013

On 13/02/13 05:32, the mail apparently from Larry Hayes included:
> I am using v1.0 of the library.
> Configure Options:  --disable-static --enable-shared --enable-openssl
> --enable-libcrypto --with-client-cert-dir=xxxx
> This is a NON-SSL web socket connection.
> I create both the Client and Server to support the
> libwebsocket_internal_extensions.
> My question is should deflate-frame extension support more than the
> MAX_USER_RX_BUFFER size of data?
> For Example:
> Client calls libwebsocket_write with a buffer of 4119, of that UserData
> is 4097. I see this gets compressed to 206 bytes.
> Which the server receives, 206 bytes, but it inflates to 4096 bytes of
> user data.

For the reception / inflate side, the MAX_USER_RX_BUFFER (this got 
removed after 1.0, you can set it per-protocol in the protocol struct 
now) limit only applies to the compressed frame content.

So your compressed payload of 206 is well below the default limit of 4096.

The inflated data gets its own malloc'd buffer with a different max size 
restriction, LWS_MAX_ZLIB_CONN_BUFFER, 64KBytes by default.  So there's 
no problem dealing with 4097 bytes of data there either.

That inflated buffer and the length are passed directly then to the user 
callback untouched.

I also studied the client send side and couldn't see how that could go 
wrong either.

> libwebsockets_remaining_packet_payload tells me no more bytes. But I am
> missing 1 byte of data.

That's telling you about the compressed data in the actual frame... and 
indeed the receiving peer had gotten all 206 bytes of that.

deflate-frame extension should only deliver atomic frames, so there 
should never be any left over, so 0 is correct from that POV too.

> The strange thing, if the server goes to close the connection, the
> client will write 2 more bytes before the CALLBACK_CLOSED is called.
> Anybody have an idea what is going on here?

Those 2 bytes sound like the 2-byte reason code in the CLOSE frame, if 
that's the case they're not related to your main problem.

I attach a test patch I used to try to reproduce the problem, I did not 
find any trouble on HEAD receiving a 4097 byte packet at the server 
through deflate-frame, when the max normal frame size was set to 4096.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-4097-issue.patch
Type: text/x-patch
Size: 12741 bytes
Desc: not available
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20130213/de1c691a/attachment.bin>

More information about the Libwebsockets mailing list