curl / Mailing Lists / curl-library / Single Mail
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: more WebSockets

From: Felipe Gasper via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 11 Aug 2021 19:12:52 -0400

> On Aug 11, 2021, at 6:34 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Wed, 11 Aug 2021, Felipe Gasper wrote:
>
>> Why frame by frame? JS’s API only does full messages, and I think the RFC actually stipulates that.
>
> When a single frame can be 61 bits large?

I believe most implementations enforce a maximum message length. Mojolicious (Perl), for example, stipulates 256 KiB by default. (https://metacpan.org/pod/Mojo::Transaction::WebSocket#max_websocket_size) I think Firefox is 2 GiB.

WS close code 1009 serves this purpose.

This can be enforced without receiving a full frame: parse the frame header, determine the size, add it to the previously-received size, and if it exceeds the limit, fail the connection.

That said, the RFC does, I now see, explicitly allow for streaming-type interfaces that give individual frame contents to the application. Frame boundaries, though, don’t have the same guarantees that message boundaries do; intermediaries/proxies are free to reshuffle those as they wish. (With TLS now being so prevalent that _probably_ doesn’t happen very often, though.)

-F
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-08-12