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: curl websockets
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Felipe Gasper via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 3 Jul 2021 06:43:53 -0400
> On Jul 2, 2021, at 9:07 PM, Dmitry Karpov via curl-library <curl-library_at_cool.haxx.se> wrote:
>
>> could libcurl wait for all the fragmented messages to arrive, then concat them and serve the completed message to the calling application?
>
> I don't think it is possible in all the cases. WebSocket text/data messages can have 64-bit length, so it is just not possible to assemble large messages.
> I implemented WebSocket protocol in some C++ curl-based client and I used the following approach:
>
> 1. Notify client that some WS not control message (i.e. text/data) has arrived.
> 2. In the notification callback, Client either provides a buffer to store the message (can be useful for short messages) or data writing callback to store large messages (where data concatenation is not feasible).
> - If provided buffer is too small to hold the message, then we need to handle it as WebSocket protocol prescribes - close WS connection with 1009 'Buffer too small' error code.
>
> 3. I also provided a special callback for incoming control messages (i.e. Ping) while large data messages are being received, so client can handle multiple messages (one large data and multiple control messages at the same time) at the same time.
Curl will have to allocate a buffer for each frame’s data anyway; maybe just give that buffer to the callback? Then allow the caller either to assume ownership of it, or free the buffer after the callback is done.
> WebSocket protocol is very specific about how and when WS connection should handle certain errors, and which status codes should be used in different connection closure cases, so sometimes some specific transport errors (like Tls handshake errors) should be explicitly handled and reported as WS connection closures with specific status codes (i.e. 1015 'TLS handshake failure').
1015 is an interesting one … I guess it’s for a STARTTLS-type workflow where the TLS rides on WebSocket?
Regarding connection closures, WebSocket seems to follow SCTP’s model; that may be useful prior art to consult.
-F
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-03
Date: Sat, 3 Jul 2021 06:43:53 -0400
> On Jul 2, 2021, at 9:07 PM, Dmitry Karpov via curl-library <curl-library_at_cool.haxx.se> wrote:
>
>> could libcurl wait for all the fragmented messages to arrive, then concat them and serve the completed message to the calling application?
>
> I don't think it is possible in all the cases. WebSocket text/data messages can have 64-bit length, so it is just not possible to assemble large messages.
> I implemented WebSocket protocol in some C++ curl-based client and I used the following approach:
>
> 1. Notify client that some WS not control message (i.e. text/data) has arrived.
> 2. In the notification callback, Client either provides a buffer to store the message (can be useful for short messages) or data writing callback to store large messages (where data concatenation is not feasible).
> - If provided buffer is too small to hold the message, then we need to handle it as WebSocket protocol prescribes - close WS connection with 1009 'Buffer too small' error code.
>
> 3. I also provided a special callback for incoming control messages (i.e. Ping) while large data messages are being received, so client can handle multiple messages (one large data and multiple control messages at the same time) at the same time.
Curl will have to allocate a buffer for each frame’s data anyway; maybe just give that buffer to the callback? Then allow the caller either to assume ownership of it, or free the buffer after the callback is done.
> WebSocket protocol is very specific about how and when WS connection should handle certain errors, and which status codes should be used in different connection closure cases, so sometimes some specific transport errors (like Tls handshake errors) should be explicitly handled and reported as WS connection closures with specific status codes (i.e. 1015 'TLS handshake failure').
1015 is an interesting one … I guess it’s for a STARTTLS-type workflow where the TLS rides on WebSocket?
Regarding connection closures, WebSocket seems to follow SCTP’s model; that may be useful prior art to consult.
-F
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-03