[Libwebsockets] Deflate Frame Extension Question

Andy Green andy at warmcat.com
Wed Feb 13 23:24:30 CET 2013

Hi -

I guess so... however that while loop behavior with many reallocs per frame for payload data is objectionable, I have my eye on removing the looping for a different scheme.

It's probably better to work with the latest release fwiw, it's certainly easier to take care of bugs there.


Larry Hayes <lhayesg at gmail.com> wrote:

>Thanks for the time looking into it.
>I tried v1.1 this morning and it works.
>I am assuming this is a v1.0 issue.
>I do not see LWS_MAX_ZLIB_CONN_BUFFER defined in 1.0.
>I did notice in v1.0 there is no while loop around the inflate as there
>in v1.1
>On Tue, Feb 12, 2013 at 9:42 PM, "Andy Green (林安廸)"
><andy at warmcat.com>wrote:
>> 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-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
>>> is 4097. I see this gets compressed to 206 bytes.
>>> Which the server receives, 206 bytes, but it inflates to 4096 bytes
>>> user data.
>> For the reception / inflate side, the MAX_USER_RX_BUFFER (this got
>> after 1.0, you can set it per-protocol in the protocol struct now)
>> only applies to the compressed frame content.
>> So your compressed payload of 206 is well below the default limit of
>> The inflated data gets its own malloc'd buffer with a different max
>> 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
>> callback untouched.
>> I also studied the client send side and couldn't see how that could
>> 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...
>> indeed the receiving peer had gotten all 206 bytes of that.
>> deflate-frame extension should only deliver atomic frames, so there
>> 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,
>> 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
>> find any trouble on HEAD receiving a 4097 byte packet at the server
>> deflate-frame, when the max normal frame size was set to 4096.
>> -Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20130214/549c92eb/attachment-0001.html>

More information about the Libwebsockets mailing list