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: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 3 Jul 2026 09:05:53 +0200
> Am 03.07.2026 um 08:24 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> On Thu, 2 Jul 2026, Dmitry Karpov via curl-library wrote:
>
>> 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.
>
> Your discussion here is focused on the connection part, but a share handle can share several other things apart from that and if we are going to allow ripping out the carpet under our feet while standing on it we need to make sure that everything standing on that carpet deals with that properly.
>
> Since the sharing system was not designed to be dynamically added and removed during a transfer, we have not documented how that works and we have not had a consistent way dealing with it in code either. Whatever worked in 8.6.0 or not.
>
> curl_easy_setopt() itself is a function that was designed and intended to set options in a handle BEFORE a transfer starts, as it defines the properties for the upcoming transfer. That is why the man page for curl_easy_setopt() states:
>
> Changing options with curl_easy_setopt(3) while a transfer is still in
> progress may cause undefined and undesired behavior.
>
> Another detail that we/I always *thought* and designed for, but it was not always spelled out clearly in the documentation. But also, because it was always the idea, we don't have tests for changing options mid-transfer to make sure that works. Because it was never how the function was meant to be used.
>
>> it was a legitimate use case to build logic using that order of libcurl calls back then
>
> It worked, yes. It was not how we intended or designed the option to be used.
>
> I suppose the easiest and possibly best fix to this issue is to just return error if the user tries to set the share to NULL before the transfer is complete.
>
>> That's may become a surprise for folks who have long libcurl upgrade cycles like it was in my case.
>
> Right. Unfortunate, but true.
>
>> 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.
>
> It's not rocket science. It's just code. Any half-decent developer can read code and learn this. It's more a matter of will, time and energy for it. You need all three.
>
>> I think that someone like Stefan should probably look at it and do the changes.
>
> You're a commercial user of libcurl who use it for free and you ask a volounteer to fix your problem on his spare time? I'm not Stefan, but I felt a need to highlight this imballance.
Rightly so.
Dimitry, this is open source. You can take the source as it is, make your own version or pay someone to do the changes you need.
You have a history here of asking for things to make your use case better, and your company has not contributed anything back to my knowledge. I feel no obligation to do your bidding (as you dropped my name here).
Cheers,
Stefan
Date: Fri, 3 Jul 2026 09:05:53 +0200
> Am 03.07.2026 um 08:24 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> On Thu, 2 Jul 2026, Dmitry Karpov via curl-library wrote:
>
>> 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.
>
> Your discussion here is focused on the connection part, but a share handle can share several other things apart from that and if we are going to allow ripping out the carpet under our feet while standing on it we need to make sure that everything standing on that carpet deals with that properly.
>
> Since the sharing system was not designed to be dynamically added and removed during a transfer, we have not documented how that works and we have not had a consistent way dealing with it in code either. Whatever worked in 8.6.0 or not.
>
> curl_easy_setopt() itself is a function that was designed and intended to set options in a handle BEFORE a transfer starts, as it defines the properties for the upcoming transfer. That is why the man page for curl_easy_setopt() states:
>
> Changing options with curl_easy_setopt(3) while a transfer is still in
> progress may cause undefined and undesired behavior.
>
> Another detail that we/I always *thought* and designed for, but it was not always spelled out clearly in the documentation. But also, because it was always the idea, we don't have tests for changing options mid-transfer to make sure that works. Because it was never how the function was meant to be used.
>
>> it was a legitimate use case to build logic using that order of libcurl calls back then
>
> It worked, yes. It was not how we intended or designed the option to be used.
>
> I suppose the easiest and possibly best fix to this issue is to just return error if the user tries to set the share to NULL before the transfer is complete.
>
>> That's may become a surprise for folks who have long libcurl upgrade cycles like it was in my case.
>
> Right. Unfortunate, but true.
>
>> 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.
>
> It's not rocket science. It's just code. Any half-decent developer can read code and learn this. It's more a matter of will, time and energy for it. You need all three.
>
>> I think that someone like Stefan should probably look at it and do the changes.
>
> You're a commercial user of libcurl who use it for free and you ask a volounteer to fix your problem on his spare time? I'm not Stefan, but I felt a need to highlight this imballance.
Rightly so.
Dimitry, this is open source. You can take the source as it is, make your own version or pay someone to do the changes you need.
You have a history here of asking for things to make your use case better, and your company has not contributed anything back to my knowledge. I feel no obligation to do your bidding (as you dropped my name here).
Cheers,
Stefan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-07-03