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.html
