Buy commercial curl support. 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 Daniel himself.
Re: Fewer promises to abide to CA changes in connection reuse
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Demi Marie Obenour <demiobenour_at_gmail.com>
Date: Wed, 21 Oct 2026 21:17:44 -0400
On 10/21/26 14:49, Peter Krefting via curl-library wrote:
> Hi!
>
> 2026-10-20 17:50 skrev Daniel Stenberg via curl-library:
>
>> I want to loosen up our rules around this because I don't think we need
>> them and I don't think users actually toggle and change all those
>> options in the same handle and even if they do, they don't get hurt if
>> such connections are reused.
>
> At $DAYJOB we do just that; we have a shared curl handle for each
> running thread and run sequential connections with different options
> (such as CA cert, client cert) through that handle.
>
> I don't think that would be a problem, however, as if this is documented
> as not being supported, we can move to a model where we use one curl
> handle per set of configuration options. We do not do parallel
> connections in a single thread, so I don't think that would impact
> performance much.
>
>
> Otherwise, having an API call saying "hey! I'm reusing this handle for a
> different set of options" that would disqualify the handle for
> connection reuse could potentially be useful.
In light of this, I think it’s best to keep the rules as is. Otherwise,
it could lead to silent regressions when libcurl is updated, perhaps by
the distribution.
Received on 2026-10-22
Date: Wed, 21 Oct 2026 21:17:44 -0400
On 10/21/26 14:49, Peter Krefting via curl-library wrote:
> Hi!
>
> 2026-10-20 17:50 skrev Daniel Stenberg via curl-library:
>
>> I want to loosen up our rules around this because I don't think we need
>> them and I don't think users actually toggle and change all those
>> options in the same handle and even if they do, they don't get hurt if
>> such connections are reused.
>
> At $DAYJOB we do just that; we have a shared curl handle for each
> running thread and run sequential connections with different options
> (such as CA cert, client cert) through that handle.
>
> I don't think that would be a problem, however, as if this is documented
> as not being supported, we can move to a model where we use one curl
> handle per set of configuration options. We do not do parallel
> connections in a single thread, so I don't think that would impact
> performance much.
>
>
> Otherwise, having an API call saying "hey! I'm reusing this handle for a
> different set of options" that would disqualify the handle for
> connection reuse could potentially be useful.
In light of this, I think it’s best to keep the rules as is. Otherwise,
it could lead to silent regressions when libcurl is updated, perhaps by
the distribution.
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature