curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Detecting final WebSocket frame of a fragmented message

From: Paul Fotheringham via curl-library <>
Date: Sat, 15 Jul 2023 11:58:46 +0100

>> On Wed, 12 Jul 2023 at 11:25, Mike Duglas via curl-library
>> <> wrote:
>> >
>> > Hi,
>> >
>> > bytesleft == 0 means no more data in this frame.
>> > bytesleft == 0 and CURLWS_CONT bit is not set means the end of the message.
>> >
>> > --
>> > Mike
>> Thanks for the reply.
>> Unfortunately that does not seem to be the case for me. I fragment my
>> message into eight frames and the first frame does not have the
>> CURLWS_CONT bit set, the following seven frames do. This is what I
>> would expect if CURLWS_CONT has the same meaning as the continuation
>> frame opcode.
>>On Sat, 15 Jul 2023 at 11:24, Mike Duglas <> wrote:
> Hi Paul,
> Looks like something has changed or broken since I tested websockets in libcurl 7.88. In all builds of libcurl 8.x my tests now fail.
> Sorry for misleading you.
> --
> Mike

Hey no problem Mike, just glad I'm not missing something. I have not
tested my receiving code against the real world server that it is
designed for so this may be a theoretical issue for me at the moment
if that server never fragments, we'll see.

I can try to trace down the change and offer a fix if you want?

Since the behaviour you describe is the intended behaviour, in that
your tests passed with it, it might be worth pointing out in the
documentation that CURLWS_CONT has a different meaning to the
continuation frame opcode. I must admit I kind of prefer it the way it
currently is as it more closely maps on to the websocket spec and
would rather have a CURLWS_FIN flag in there but that's just my
thoughts. Do you know why libcurl doesn't just expose the opcode
directly and instead opts for a bit field?


PS. I've tried replying to my original email so that the archive has a
sensible chain. I did not realise I had replied to a digest reply in
my last email. Apologies.
Received on 2023-07-15