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.
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, 31 Oct 2022 09:34:45 -0400
Hello,
I’m looking over curl’s provisional WebSocket support--an exciting development, to be sure!
Here are a few notes I’ve made from just looking over the API. I have not, as Thomas has, actually written code against it; still, hopefully these will be of use:
- The documentation would do well to clarify that what this API returns (and expects) are WebSocket *frames*, not messages. Thus, applications are responsible for aggregating fragmented messages (i.e., looking at the FIN flag) themselves. Are those applications also responsible for validating frame opcodes?
RFC 6455 seems more or less to assume that WebSocket implementations will expose concatenated messages rather than frames 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.
- Speaking of close, I assume applications are responsible for verifying, if curl sends the close frame, that the close response matches the sent one?
- 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
This seems rather counterintuitive given that the actual WS frame opcodes will be TEXT, CONT, and CONT (with FIN on the last one). Perhaps CURLWS_NONFINAL would be an improvement upon CURLWS_CONT?
Alternatively, maybe CURLWS_CONT is meant to indicate opcode=CONT … but then what distinguishes CONT|FIN from plain CONT?
- Does this implementation currently support WebSocket compression (PMCE)? I see no mention of it.
Note that the relevant RFC (7692) stipulates (section 6) that compression/decompression happen on concatenated payloads, so curl’s current frame-oriented WebSocket API might be problematic. That said, LibWebsockets is also frame-oriented, and it seems to be OK decompressing frame-by-frame. Maybe it only happens to work with gzip, though, and some other future compression (e.g., zstd) would fail.
- I see the CLI plan for sending PINGs. Note that there’s also a legit use case for sending periodic PONGs without a PING. An application I maintain transfers mysqldump output across a WS connection and inserts it line-by-line into a target host’s MySQL. When the target host enables keys on the new table, this takes a while, which causes backpressure on the stream. So the sender can’t send or answer PINGs … but if we send *nothing*, the router may drop the connection. So we have the target send unrequested PONGs every minute or so, which keeps the router from making trouble while MySQL does its thing.
- Small nit: the link to LibWebsockets is wrong.
Thank you!
cheers,
-Felipe
Date: Mon, 31 Oct 2022 09:34:45 -0400
Hello,
I’m looking over curl’s provisional WebSocket support--an exciting development, to be sure!
Here are a few notes I’ve made from just looking over the API. I have not, as Thomas has, actually written code against it; still, hopefully these will be of use:
- The documentation would do well to clarify that what this API returns (and expects) are WebSocket *frames*, not messages. Thus, applications are responsible for aggregating fragmented messages (i.e., looking at the FIN flag) themselves. Are those applications also responsible for validating frame opcodes?
RFC 6455 seems more or less to assume that WebSocket implementations will expose concatenated messages rather than frames 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.
- Speaking of close, I assume applications are responsible for verifying, if curl sends the close frame, that the close response matches the sent one?
- 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
This seems rather counterintuitive given that the actual WS frame opcodes will be TEXT, CONT, and CONT (with FIN on the last one). Perhaps CURLWS_NONFINAL would be an improvement upon CURLWS_CONT?
Alternatively, maybe CURLWS_CONT is meant to indicate opcode=CONT … but then what distinguishes CONT|FIN from plain CONT?
- Does this implementation currently support WebSocket compression (PMCE)? I see no mention of it.
Note that the relevant RFC (7692) stipulates (section 6) that compression/decompression happen on concatenated payloads, so curl’s current frame-oriented WebSocket API might be problematic. That said, LibWebsockets is also frame-oriented, and it seems to be OK decompressing frame-by-frame. Maybe it only happens to work with gzip, though, and some other future compression (e.g., zstd) would fail.
- I see the CLI plan for sending PINGs. Note that there’s also a legit use case for sending periodic PONGs without a PING. An application I maintain transfers mysqldump output across a WS connection and inserts it line-by-line into a target host’s MySQL. When the target host enables keys on the new table, this takes a while, which causes backpressure on the stream. So the sender can’t send or answer PINGs … but if we send *nothing*, the router may drop the connection. So we have the target send unrequested PONGs every minute or so, which keeps the router from making trouble while MySQL does its thing.
- Small nit: the link to LibWebsockets is wrong.
Thank you!
cheers,
-Felipe
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-10-31