by implementations to signal
> something without negotiating 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 "r
> 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 t
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 r
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 yo
>> 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 a
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 enforce
Hi Daniel,
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.
Summarizing this approach, it seems that libcurl will provide the following:
1. WS handshake handling
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, support
> 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 f
12 matches
Mail list logo
