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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 7 Nov 2022 08:44:50 +0100 (CET)
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.
> Thus, applications are responsible for aggregating fragmented messages
> (i.e., looking at the FIN flag) themselves.
The ws protocol flags are not exposed in the API.
Applications get/send a full fragment or a piece of a fragment in each
function call.
> Are those applications also responsible for validating frame opcodes?
The applications don't get to see any opcodes so they cannot validate them.
(unless they use raw mode but I presume we don't talk about that mode)
> RFC 6455 seems more or less to assume that WebSocket implementations will
> expose concatenated messages rather than frames to applications.
A single fragment can be 63 bit large. A message consists of multiple
fragments and can thus be infinitely large. How would we expose such "full
messages" to applications?
> 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.
> - Speaking of close, I assume applications are responsible for verifying, if
> curl sends the close frame, that the close response matches the sent one?
I don't understand. Match a close frame how?
> - 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.
> Perhaps CURLWS_NONFINAL would be an improvement upon CURLWS_CONT?
Naming is hard. "Non-final" vs "continued". I don't see a big difference.
> Alternatively, maybe CURLWS_CONT is meant to indicate opcode=CONT … but then
> what distinguishes CONT|FIN from plain CONT?
A delivered frame/fragment is either the last one in a message or not the last
one. Does it need more than one bit to signal that?
> - Does this implementation currently support WebSocket compression (PMCE)? I
> see no mention of it.
It does not, so it does not mention it.
> - Small nit: the link to LibWebsockets is wrong.
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...
Date: Mon, 7 Nov 2022 08:44:50 +0100 (CET)
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.
> Thus, applications are responsible for aggregating fragmented messages
> (i.e., looking at the FIN flag) themselves.
The ws protocol flags are not exposed in the API.
Applications get/send a full fragment or a piece of a fragment in each
function call.
> Are those applications also responsible for validating frame opcodes?
The applications don't get to see any opcodes so they cannot validate them.
(unless they use raw mode but I presume we don't talk about that mode)
> RFC 6455 seems more or less to assume that WebSocket implementations will
> expose concatenated messages rather than frames to applications.
A single fragment can be 63 bit large. A message consists of multiple
fragments and can thus be infinitely large. How would we expose such "full
messages" to applications?
> 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.
> - Speaking of close, I assume applications are responsible for verifying, if
> curl sends the close frame, that the close response matches the sent one?
I don't understand. Match a close frame how?
> - 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.
> Perhaps CURLWS_NONFINAL would be an improvement upon CURLWS_CONT?
Naming is hard. "Non-final" vs "continued". I don't see a big difference.
> Alternatively, maybe CURLWS_CONT is meant to indicate opcode=CONT … but then
> what distinguishes CONT|FIN from plain CONT?
A delivered frame/fragment is either the last one in a message or not the last
one. Does it need more than one bit to signal that?
> - Does this implementation currently support WebSocket compression (PMCE)? I
> see no mention of it.
It does not, so it does not mention it.
> - Small nit: the link to LibWebsockets is wrong.
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...
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-11-07