Re: Wrong connection reuse case for Share interface

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.

-- 

  / daniel.haxx.se || https://rock-solid.curl.dev
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html