When using the LWS client to fetch a large compressed message, we find the message body is truncated - or at least, lws_is_final_fragment returns nonzero before the uncompressed message body has been fully read.
We've seen the same behavior in versions 4.4, 4.5 and 5.0, but not in 4.3.
We've attached an example demonstrating this issue - to reproduce:
Build with cmake, e.g.:
cmake -B build -G "Visual Studio 17 2022" -Dlibwebsockets_DIR=<path-to-lws-build-folder>
cmake --build build --config Release
Then run in one command-prompt:
pmd-final-bug-server -c -b
This starts a server that will emit a 156400-byte message (before compression). Then in another command-prompt, run the client to read this message:
However, for us the client only actually reads 90807 (uncompressed) bytes, because lws_is_final_fragment is returning nonzero too early. If you run the client and server with the -n flags to disable extensions, you'll see it reads the correct number of bytes.
repro-pmd-final-bug.zip
When using the LWS client to fetch a large compressed message, we find the message body is truncated - or at least, lws_is_final_fragment returns nonzero before the uncompressed message body has been fully read.
We've seen the same behavior in versions 4.4, 4.5 and 5.0, but not in 4.3.
We've attached an example demonstrating this issue - to reproduce:
Build with cmake, e.g.:
Then run in one command-prompt:
This starts a server that will emit a 156400-byte message (before compression). Then in another command-prompt, run the client to read this message:
However, for us the client only actually reads 90807 (uncompressed) bytes, because lws_is_final_fragment is returning nonzero too early. If you run the client and server with the
-nflags to disable extensions, you'll see it reads the correct number of bytes.repro-pmd-final-bug.zip