Great, thanks for verifying,
Much appreciated,
-Josh
On Thu, Aug 12, 2021 at 6:11 AM Daniel Stenberg wrote:
> On Fri, 6 Aug 2021, Joshua Harlow via curl-library wrote:
>
> > When pausing and resuming I was noticing that CURLINFO_SPEED_UPLOAD and
> > CURLINFO_SPEED_DOWNLOAD and its
Hi!
There is curl_easy_strerror() for CURLcode, curl_multi_strerror() for
CURLMcode, curl_share_strerror() for CURLSHcode, but there seems to be
no way to convert CURLUcode value into string:
https://curl.se/libcurl/c/libcurl-errors.html
Would be nice to have something like:
const char
> If you by "assembling" mean concatenating multiple frames until the FIN
> frame, then my thinking was yes, so that we wouldn't have to buffer up
> potentially a large amount of data before passing it on.
> How do other client implementations work and how do they handle the unlimited
>
Hi all,
Regarding the plan to add WebSocket to curl, would it be useful to
consider, instead of writing a new implementation, incorporating an existing
library?
I’ve worked a bit with libwebsockets, which seems quite complete. Until
recently it didn’t integrate into a custom
On Fri, 6 Aug 2021, Joshua Harlow via curl-library wrote:
When pausing and resuming I was noticing that CURLINFO_SPEED_UPLOAD and
CURLINFO_SPEED_DOWNLOAD and its counters/timers don't seem to reset (which
may just be how it is) and from looking at the progress.c code I think this
is what is
> 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
12 matches
Mail list logo
