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: Felipe Gasper via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 7 Nov 2022 10:46:20 -0500
> On Nov 7, 2022, at 02:44, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Mon, 31 Oct 2022, Felipe Gasper via curl-library wrote:
>
> Let me start by repeating that I myself is not experienced user of any websocket API. I rely on feedback from users who are. The API is not written in stone yet. We can and will adapt where we deem it necessary.
>
>> - The documentation would do well to clarify that what this API returns (and expects) are WebSocket *frames*, not messages.
>
> It works on fragments, or pieces of fragments. Documentation is hard so feel free to propose improvements.
I’ll be happy to.
>> curl could implement this safely by having a max-message-size, and once a frame header indicates that a message is going to exceed that, send a close of type 1009, and discard every incoming frame until the close response arrives.
>
> I was previously told if fairly clear words that at least 64K is far from being a fine maximum size, which to me implies that we need to support fairly large sizes by default and thus need to deal with them in a "streaming manner".
>
> We could perhaps still have a max-message-size option.
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.
>> - 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)?
>> Perhaps CURLWS_NONFINAL would be an improvement upon CURLWS_CONT?
>
> Naming is hard. "Non-final" vs "continued". I don't see a big difference.
Both “noninitial” (i.e., opcode=0) and “nonfinal” frames could be described intuitively as “CONT”.
A reader of the API could be forgiven, I think, for thinking CURLWS_CONT meant “continuation” rather than “continued”. CURLWS_NONFINAL avoids that. Particularly if that reader knows the underlying WebSocket protocol, which uses “CONT”(-inuation) to mean “noninitial” rather than “nonfinal”.
> I dislike how the RFC speak of WebSocket in singular form all over, but almost nothing else in the world does and instead WebSockets in plural is what seems to be used widely...
“Websockets” adhere to the “websocket” protocol. At least, that’s how I juggle it mentally.
On CPAN and Ruby Gems, at least, the singular form seems prevalent.
-FG
Date: Mon, 7 Nov 2022 10:46:20 -0500
> On Nov 7, 2022, at 02:44, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Mon, 31 Oct 2022, Felipe Gasper via curl-library wrote:
>
> Let me start by repeating that I myself is not experienced user of any websocket API. I rely on feedback from users who are. The API is not written in stone yet. We can and will adapt where we deem it necessary.
>
>> - The documentation would do well to clarify that what this API returns (and expects) are WebSocket *frames*, not messages.
>
> It works on fragments, or pieces of fragments. Documentation is hard so feel free to propose improvements.
I’ll be happy to.
>> curl could implement this safely by having a max-message-size, and once a frame header indicates that a message is going to exceed that, send a close of type 1009, and discard every incoming frame until the close response arrives.
>
> I was previously told if fairly clear words that at least 64K is far from being a fine maximum size, which to me implies that we need to support fairly large sizes by default and thus need to deal with them in a "streaming manner".
>
> We could perhaps still have a max-message-size option.
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.
>> - 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)?
>> Perhaps CURLWS_NONFINAL would be an improvement upon CURLWS_CONT?
>
> Naming is hard. "Non-final" vs "continued". I don't see a big difference.
Both “noninitial” (i.e., opcode=0) and “nonfinal” frames could be described intuitively as “CONT”.
A reader of the API could be forgiven, I think, for thinking CURLWS_CONT meant “continuation” rather than “continued”. CURLWS_NONFINAL avoids that. Particularly if that reader knows the underlying WebSocket protocol, which uses “CONT”(-inuation) to mean “noninitial” rather than “nonfinal”.
> I dislike how the RFC speak of WebSocket in singular form all over, but almost nothing else in the world does and instead WebSockets in plural is what seems to be used widely...
“Websockets” adhere to the “websocket” protocol. At least, that’s how I juggle it mentally.
On CPAN and Ruby Gems, at least, the singular form seems prevalent.
-FG
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-11-07