>> On Wed, 12 Jul 2023 at 11:25, Mike Duglas via curl-library >> <curl-library@lists.haxx.se> 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 <mikedugla...@gmail.com> 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? Paul 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. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
