> On Aug 11, 2021, at 6:34 PM, Daniel Stenberg <dan...@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
