Re: Wrong connection reuse case for Share interface

> 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).

Stefan, I agree with you that it is open source, and you have no obligation to fix anything.
And I, as many other libcurl users, very appreciate your work and when you fix things to make libcurl better for everyone.

But I report issues here which I think may affect not only me, but some other libcurl users as well.
Companies with large user population, like mine, can't afford do libcurl very frequently, and thus may not be aware that something that works on their libcurl version
may suddenly stop working when they upgrade to latest versions - just because it used to work by pure luck.

I think doing such reporting is part of obligations from commercial users as they may provide a test ground with a very large set of scenarios which is difficult to get otherwise.
So, I am doing my diligence in this part.

Also, whenever we do libcurl changes internally or have some ideas that we think may benefit the wider community, we always try to submit them either via PRs or proposals.
Some of these ideas/changes were accepted and some were rejected - which is a normal process, so we do try to contribute to the libcurl project, which we love and respect, whenever we can.

As for this particular issue, I think it was quite logical to ask you to look at it, as you did a lot of redesign and implementation changes in the connection management area, and may tell
if it is possible to handle this case better than UB.

Thanks!
Dmitry


-----Original Message-----
From: curl-library <[email protected]> On Behalf Of Stefan Eissing via curl-library
Sent: Friday, July 3, 2026 12:06 AM
To: libcurl development <[email protected]>
Cc: Stefan Eissing <[email protected]>
Subject: [EXTERNAL] Re: Wrong connection reuse case for Share interface



> Am 03.07.2026 um 08:24 schrieb Daniel Stenberg via curl-library <[email protected]>:
> 
> 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.html
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html