ating an extension?
In general, all extensions must be negotiated, but I saw cases when some WS
client/server implementations used reserved control opcodes for their
proprietary communication.
I guess they used it for some kind of "real-time" (as control frames are short
and has deliver
> Am 12.08.2021 um 09:33 schrieb Stefan Eissing via curl-library
> :
>
> One thing from rfc6455, ch. 5.4:
>
> "An intermediary MUST NOT change the fragmentation of a message if
> any reserved bit values are used and the meaning of these values
> is not known to the intermediary."
>
One thing from rfc6455, ch. 5.4:
"An intermediary MUST NOT change the fragmentation of a message if
any reserved bit values are used and the meaning of these values
is not known to the intermediary."
which I read as: if you want to use libcurl as an intermediary, it needs
to expose
On Thu, 12 Aug 2021, Daniel Stenberg via curl-library wrote:
Should we just impose our own maximum size and have applications raise it
when needed?
Answering myself. =)
Ok, I'm convinced we should make the API able to provide full messages. I'll
adjust acccording.
--
/ daniel.haxx.se
|
On Thu, 12 Aug 2021, Weston Schmidt wrote:
I'd like to add a flag to CURLOPT_WS_OPTIONS that tells curl if it
should negotiate compression or not for easy & multi.
I like the automatic response to pings & pongs by default. Perhaps
another CURLOPT_WS_OPTIONS flag might disable the automatic
On Wed, 11 Aug 2021, Dmitry Karpov via curl-library wrote:
Thanks for the feedback, this is very helpful!
From a brief look at the document, it looks like Curl will provide only
WebSocket frame level of communication, so the client will have to implement
full message assembling itself.
If
>> Other websockets implementations are doing that then I presume?
I'll only speak to my implementation ... I provided both a streaming
interface and a block/message interface. The block/message is nice
for small stuff if you know limits but, for all the reasons you point
out, streaming through
On Wed, 11 Aug 2021, Felipe Gasper wrote:
When a single frame can be 61 bits large?
(Of course I meant 63...)
And thanks for this. As you know I'm a WebSockets rookie so I need and
appricate pointers like this!
I believe most implementations enforce a maximum message length. Mojolicious
> On Aug 11, 2021, at 6:34 PM, Daniel Stenberg 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
or some proprietary WS communications.
Thanks,
Dmitry Karpov
-Original Message-
From: curl-library On Behalf Of Daniel
Stenberg via curl-library
Sent: Wednesday, August 11, 2021 2:41 PM
To: libcurl hacking
Cc: Daniel Stenberg
Subject: more WebSockets
Hi,
I've refreshed the wiki page a
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?
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes,
> On Aug 11, 2021, at 17:46, Daniel Stenberg via curl-library
> wrote:
>
> A single fragment can be 61 bits large and a message consists of multiple
> such fragments: we must have an API that provides data piece by piece to the
> applicaiton and signal the FIN when it arrives.
Why frame by
Hi,
I've refreshed the wiki page a bit using input from the discussion so far. See
https://github.com/curl/curl/wiki/WebSockets
A few things I realized and tried to reflect in the page:
A single fragment can be 61 bits large and a message consists of multiple such
fragments: we must have an
13 matches
Mail list logo
