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: Wrong connection reuse case for Share interface
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 2 Jul 2026 21:32:00 +0000
> I would rather say that you were lucky before, relying on a behavior that was not neither considered, enforced nor tested. So we clarified the documentation to better match reality.
Not sure, that I would entirely agree that I was lucky.
The code in 8.6.0 closed the connection in such cases as part of cleanup done by curl_multi_remove_handle(), and the documentation didn't specify that it was something that wasn't supported.
So, it was a legitimate use case to build logic using that order of libcurl calls back then, which became UB officially only in the recent builds.
That's may become a surprise for folks who have long libcurl upgrade cycles like it was in my case.
> Pull-requests are welcome!
I am not sure that the changes in that area can be done by folks without very deep knowledge of how connection management works internally in libcurl.
Because the nutshell of this problem is that the set share to NULL detaches the connection from the easy handle, and thus the curl_multi_remove_handle()
can't close it because it doesn't see it anymore.
This wasn't the case in 8.6.0 - where set share to NULL didn't detach connection from the easy handle and curl_multi_remove_handle() would close it.
I assume that the detaching was done for a reason, and a simple suggestion to not detach, as it used to be in 8.6.0. will not work or create some other issues.
As it is difficult to know and see all potential subtle issues that may result from touching this area, I think that someone like Stefan should probably look at it and do the changes.
Thanks,
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, July 2, 2026 1:31 PM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Wrong connection reuse case for Share interface
On Thu, 2 Jul 2026, Dmitry Karpov via curl-library wrote:
> Thanks for clarification. Somehow, I missed this behavior change.
I would rather say that you were lucky before, relying on a behavior that was not neither considered, enforced nor tested. So we clarified the documentation to better match reality.
> Hopefully, as you said, this case will be handled better in the future
Pull-requests are welcome!
Date: Thu, 2 Jul 2026 21:32:00 +0000
> I would rather say that you were lucky before, relying on a behavior that was not neither considered, enforced nor tested. So we clarified the documentation to better match reality.
Not sure, that I would entirely agree that I was lucky.
The code in 8.6.0 closed the connection in such cases as part of cleanup done by curl_multi_remove_handle(), and the documentation didn't specify that it was something that wasn't supported.
So, it was a legitimate use case to build logic using that order of libcurl calls back then, which became UB officially only in the recent builds.
That's may become a surprise for folks who have long libcurl upgrade cycles like it was in my case.
> Pull-requests are welcome!
I am not sure that the changes in that area can be done by folks without very deep knowledge of how connection management works internally in libcurl.
Because the nutshell of this problem is that the set share to NULL detaches the connection from the easy handle, and thus the curl_multi_remove_handle()
can't close it because it doesn't see it anymore.
This wasn't the case in 8.6.0 - where set share to NULL didn't detach connection from the easy handle and curl_multi_remove_handle() would close it.
I assume that the detaching was done for a reason, and a simple suggestion to not detach, as it used to be in 8.6.0. will not work or create some other issues.
As it is difficult to know and see all potential subtle issues that may result from touching this area, I think that someone like Stefan should probably look at it and do the changes.
Thanks,
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, July 2, 2026 1:31 PM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Wrong connection reuse case for Share interface
On Thu, 2 Jul 2026, Dmitry Karpov via curl-library wrote:
> Thanks for clarification. Somehow, I missed this behavior change.
I would rather say that you were lucky before, relying on a behavior that was not neither considered, enforced nor tested. So we clarified the documentation to better match reality.
> Hopefully, as you said, this case will be handled better in the future
Pull-requests are welcome!
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-07-02