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: Peter Krefting via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 21 Oct 2026 20:49:37 +0200
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.
Date: Wed, 21 Oct 2026 20:49:37 +0200
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.
-- \\// Peter - http://www.softwolves.pp.se/ -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-10-21