Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: more WebSockets
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 12 Aug 2021 09:42:09 +0200
> Am 12.08.2021 um 09:33 schrieb Stefan Eissing via curl-library <curl-library_at_cool.haxx.se>:
>
> 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 the frames and its bits.
>
> Since libcurl never will do any semantic interpretation of the frames, I
> would always regard it as an "intermediary".
Commenting myself:
But if one wants to disregard all this "future proof" and "maybe one day multiplexing"
thing in the standard, a re-assembly of fragments into "messages" seems useful for
an application.
>
>> Am 12.08.2021 um 09:24 schrieb Daniel Stenberg via curl-library <curl-library_at_cool.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 response
>>> behavior in the cases where an app doesn't want to respond (or delay
>>> the response, etc).
>>
>> Thanks, vert good remarks and I've added some text about it now.
>>
>> --
>>
>> / daniel.haxx.se
>> | Commercial curl support up to 24x7 is available!
>> | Private help, bug fixes, support, ports, new features
>> | https://curl.se/support.html
>> -------------------------------------------------------------------
>> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>
>
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-08-12
Date: Thu, 12 Aug 2021 09:42:09 +0200
> Am 12.08.2021 um 09:33 schrieb Stefan Eissing via curl-library <curl-library_at_cool.haxx.se>:
>
> 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 the frames and its bits.
>
> Since libcurl never will do any semantic interpretation of the frames, I
> would always regard it as an "intermediary".
Commenting myself:
But if one wants to disregard all this "future proof" and "maybe one day multiplexing"
thing in the standard, a re-assembly of fragments into "messages" seems useful for
an application.
>
>> Am 12.08.2021 um 09:24 schrieb Daniel Stenberg via curl-library <curl-library_at_cool.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 response
>>> behavior in the cases where an app doesn't want to respond (or delay
>>> the response, etc).
>>
>> Thanks, vert good remarks and I've added some text about it now.
>>
>> --
>>
>> / daniel.haxx.se
>> | Commercial curl support up to 24x7 is available!
>> | Private help, bug fixes, support, ports, new features
>> | https://curl.se/support.html
>> -------------------------------------------------------------------
>> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>
>
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-08-12