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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 3 Jul 2026 08:24:32 +0200 (CEST)
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.
Date: Fri, 3 Jul 2026 08:24:32 +0200 (CEST)
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.htmlReceived on 2026-07-03