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: WebSocket notes
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 7 Nov 2022 21:04:50 +0000
> A mode of operation where curl aggregates the frames into full messages (as browsers do) would certainly, IMO, be friendlier for the general use case, though it may complicate more optimized scenarios.
When we were discussing WS support in libcurl some time ago, I expressed that the useful way, in my view, would be supporting three modes:
1 - "Raw". It performs only Websocket handshake over HTTP and provides "raw" read/write callbacks without any frame parsing.
This mode is useful to hook any existing WS implementations.
(For example, I implemented full WS stack (frames + messages) in C++ and would like to use this mode with my WS stack before gradually transitioning to the other modes).
2. "Frames". It extends the "raw" mode and provides WS frame parsing with special "frame" callbacks.
This mode is useful to hook any existing WS message assembling code, which might implement some complex stuff like WS extensions etc.
3. "Messages". It extends the "frames" mode and provide basic WS message assembling facilities with special "message" callbacks which will suit most of use cases.
This mode is expected to provide Ping/Pong heart beating, Control messages interleaving big data fragmented data messages, proper WS close procedure and other useful basic stuff.
So as far as I can see, the current WS API provides "Raw" and "Frame" modes, and the "Messages" mode will follow in the future, so I guess we should understand the limitations
of the "frames" mode and not ask it to support something that belongs to the "Messages" mode (like WS close handshake etc.).
At the same time, I can see the desire in the "Frames" mode to be a bit different and maybe more convenient for not WS experienced users.
That's how I look at:
>> - If I understand the flags correctly, a 3-frame text message would look thus:
>>
>> 1. flags=CURLWS_TEXT|CURLWS_CONT
>> 2. flags=CURLWS_CONT
>> 3. flags=0
>
> I believe they would look like this:
>
> 1. flags=CURLWS_TEXT|CURLWS_CONT
> 2. flags=CURLWS_TEXT|CURLWS_CONT
> 3. flags=CURLWS_TEXT
>
> At least I think that's how I would prefer it to work.
> In this case the CURLWS_TEXT in 2 and 3 is just ignored, right? That being the case, could the flags just be CURLWS_CONT (for 2) and 0 (for 3)?
Here I agree with Felipe, that for users familiar with WS his way is better because it will match the WS protocol "opcode" way.
But it looks like Daniel decided to provide a different look on the WS "frames", not exactly matching the WS protocol point of view.
From my point of view, the "frames" mode should provide WS opcode value in the curl_ws_frame rather than "CURL_WS" flags.
Otherwise, it is not easy to hook existing WS message assemblers (which rely on opcode values) into the "frames" mode.
The opcode value will provide a way to handle custom opcodes and checking the FIN bit would be trivial too.
I also don't fully understand how the CURLWS_TEXT|CURLWS_CONT combination will handle protocol errors like receiving a new one-frame text message
while processing the current fragmented one.
In this case, the new message will be reported as CURLWS_TEXT thus indicating normal end of the current message, whereas it is a new text message which server sent by mistake.
Such protocol errors are "message" level errors, and they should be handled properly in the "Messages" mode, not in the "Frames" mode, unless we start kind of mixing them.
It seems to me that the current "frames" mode is trying to provide a light-weight combination of the WS frames with WS messages instead of being a pure WS frame level.
I would personally prefer the "frames" mode to be a pure WS frame level and report in the curl_ws_frame structure all the information needed to build the WS message level (i.e. opcode+FIN flag).
So, from this perspective, I am more aligned with Felipe and prefer the "frames" mode targeting users familiar with WS protocol.
Thanks,
Dmitry Karpov
Date: Mon, 7 Nov 2022 21:04:50 +0000
> A mode of operation where curl aggregates the frames into full messages (as browsers do) would certainly, IMO, be friendlier for the general use case, though it may complicate more optimized scenarios.
When we were discussing WS support in libcurl some time ago, I expressed that the useful way, in my view, would be supporting three modes:
1 - "Raw". It performs only Websocket handshake over HTTP and provides "raw" read/write callbacks without any frame parsing.
This mode is useful to hook any existing WS implementations.
(For example, I implemented full WS stack (frames + messages) in C++ and would like to use this mode with my WS stack before gradually transitioning to the other modes).
2. "Frames". It extends the "raw" mode and provides WS frame parsing with special "frame" callbacks.
This mode is useful to hook any existing WS message assembling code, which might implement some complex stuff like WS extensions etc.
3. "Messages". It extends the "frames" mode and provide basic WS message assembling facilities with special "message" callbacks which will suit most of use cases.
This mode is expected to provide Ping/Pong heart beating, Control messages interleaving big data fragmented data messages, proper WS close procedure and other useful basic stuff.
So as far as I can see, the current WS API provides "Raw" and "Frame" modes, and the "Messages" mode will follow in the future, so I guess we should understand the limitations
of the "frames" mode and not ask it to support something that belongs to the "Messages" mode (like WS close handshake etc.).
At the same time, I can see the desire in the "Frames" mode to be a bit different and maybe more convenient for not WS experienced users.
That's how I look at:
>> - If I understand the flags correctly, a 3-frame text message would look thus:
>>
>> 1. flags=CURLWS_TEXT|CURLWS_CONT
>> 2. flags=CURLWS_CONT
>> 3. flags=0
>
> I believe they would look like this:
>
> 1. flags=CURLWS_TEXT|CURLWS_CONT
> 2. flags=CURLWS_TEXT|CURLWS_CONT
> 3. flags=CURLWS_TEXT
>
> At least I think that's how I would prefer it to work.
> In this case the CURLWS_TEXT in 2 and 3 is just ignored, right? That being the case, could the flags just be CURLWS_CONT (for 2) and 0 (for 3)?
Here I agree with Felipe, that for users familiar with WS his way is better because it will match the WS protocol "opcode" way.
But it looks like Daniel decided to provide a different look on the WS "frames", not exactly matching the WS protocol point of view.
From my point of view, the "frames" mode should provide WS opcode value in the curl_ws_frame rather than "CURL_WS" flags.
Otherwise, it is not easy to hook existing WS message assemblers (which rely on opcode values) into the "frames" mode.
The opcode value will provide a way to handle custom opcodes and checking the FIN bit would be trivial too.
I also don't fully understand how the CURLWS_TEXT|CURLWS_CONT combination will handle protocol errors like receiving a new one-frame text message
while processing the current fragmented one.
In this case, the new message will be reported as CURLWS_TEXT thus indicating normal end of the current message, whereas it is a new text message which server sent by mistake.
Such protocol errors are "message" level errors, and they should be handled properly in the "Messages" mode, not in the "Frames" mode, unless we start kind of mixing them.
It seems to me that the current "frames" mode is trying to provide a light-weight combination of the WS frames with WS messages instead of being a pure WS frame level.
I would personally prefer the "frames" mode to be a pure WS frame level and report in the curl_ws_frame structure all the information needed to build the WS message level (i.e. opcode+FIN flag).
So, from this perspective, I am more aligned with Felipe and prefer the "frames" mode targeting users familiar with WS protocol.
Thanks,
Dmitry Karpov
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-11-07