> On Nov 7, 2022, at 02:44, Daniel Stenberg <dan...@haxx.se> wrote: > > On Mon, 31 Oct 2022, Felipe Gasper via curl-library wrote: > > Let me start by repeating that I myself is not experienced user of any > websocket API. I rely on feedback from users who are. The API is not written > in stone yet. We can and will adapt where we deem it necessary. > >> - The documentation would do well to clarify that what this API returns (and >> expects) are WebSocket *frames*, not messages. > > It works on fragments, or pieces of fragments. Documentation is hard so feel > free to propose improvements.
I’ll be happy to. >> 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. > > I was previously told if fairly clear words that at least 64K is far from > being a fine maximum size, which to me implies that we need to support fairly > large sizes by default and thus need to deal with them in a "streaming > manner". > > We could perhaps still have a max-message-size option. A mode of operation where curl aggregates the frames into full messages (as browsers do) would certainly, IMO, be friendlier for the general use case, though it may complicate more optimized scenarios. >> - 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 > > I believe they would look like this: > > 1. flags=CURLWS_TEXT|CURLWS_CONT > 2. flags=CURLWS_TEXT|CURLWS_CONT > 3. flags=CURLWS_TEXT > > At least I think that's how I would prefer it to work. In this case the CURLWS_TEXT in 2 and 3 is just ignored, right? That being the case, could the flags just be CURLWS_CONT (for 2) and 0 (for 3)? >> Perhaps CURLWS_NONFINAL would be an improvement upon CURLWS_CONT? > > Naming is hard. "Non-final" vs "continued". I don't see a big difference. Both “noninitial” (i.e., opcode=0) and “nonfinal” frames could be described intuitively as “CONT”. A reader of the API could be forgiven, I think, for thinking CURLWS_CONT meant “continuation” rather than “continued”. CURLWS_NONFINAL avoids that. Particularly if that reader knows the underlying WebSocket protocol, which uses “CONT”(-inuation) to mean “noninitial” rather than “nonfinal”. > I dislike how the RFC speak of WebSocket in singular form all over, but > almost nothing else in the world does and instead WebSockets in plural is > what seems to be used widely... “Websockets” adhere to the “websocket” protocol. At least, that’s how I juggle it mentally. On CPAN and Ruby Gems, at least, the singular form seems prevalent. -FG -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
