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: Fri, 3 Jul 2026 23:40:30 +0000
> 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.
If it is a part of a larger limitation of calling curl_easy_setopt() while transfer is in progress, then the curl_easy_setopt() should probably return some error code on any option
if it is called while transfer is in progress.
It will be similar to prohibiting calling libcurl APIs inside most of callback functions - which is also used to work "by pure luck" until it was explicitly prohibited in some release.
This will help to avoid any UB which setting options during transfer in progress may cause.
In my case, it would fail our tests during libcurl upgrade, and we would be able to catch this issue before our users suffered from it.
> 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.
Yes, that's true - "everyone can code", especially in AI era, but it doesn't mean they always should.
Once code in some area becomes quite complex, and has a long history of handling complicated issues, it is better to ask domain experts to look at it the issue first and provide their opinion
before doing any changes.
It will be no good spending time and effort to make changes in some sensitive area only to get them rejected by some domain expert who sees immediately that it breaks something unexpectedly or
doesn't correctly handle some nuances.
For example, I saw a difference of how the null share setting on transfer in progress was handled in 8.6.0, where it cleaned the abandoned connection later during removing easy handle from multi handle,
and the current code, but looking at the code, it is not clear to me why the same thing can't be done now - that's the reason why I suggested to ask an expert in this area to look at this issue.
> 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.
To be clear, I didn't mean to ask to fix the problem right away, and I just meant to ask an expert in this area who redesigned and reimplemented many parts of connection management and protocol handling to look at it and possibly provide an input if it can be fixed easily and maybe do the changes if it doesn't take a lot of efforts.
And I did it only because you mentioned that you might provide a better solution to it.
And yes, I am a commercial user, who uses libcurl on a very complicated streaming platform with 100M+ users in many countries.
We pay our price of using libcurl inside very complex multi-language frameworks and 3rd party code which we can't control and change,
and where even a small libcurl issue may have financial, reputational, human, and other serious consequences.
But we do our contribution to libcurl project in a way that we use libcurl in a wide range of scenarios with different ISPs, regions, CDNs, routers etc,
and diligently report issues which we think may affect other libcurl users as well.
It would be much easier for me not to report the issues like this one, just to avoid reminders that I am getting "a free lunch" from hard working volunteers,
and handle them somehow internally, but I think that it is worth effort to report them, because I don't think that our use cases are unique and some folks may step on such issues as well.
Hopefully, I was able to get some understanding.
Thanks,
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, July 2, 2026 11:25 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:
> 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 23:40:30 +0000
> 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.
If it is a part of a larger limitation of calling curl_easy_setopt() while transfer is in progress, then the curl_easy_setopt() should probably return some error code on any option
if it is called while transfer is in progress.
It will be similar to prohibiting calling libcurl APIs inside most of callback functions - which is also used to work "by pure luck" until it was explicitly prohibited in some release.
This will help to avoid any UB which setting options during transfer in progress may cause.
In my case, it would fail our tests during libcurl upgrade, and we would be able to catch this issue before our users suffered from it.
> 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.
Yes, that's true - "everyone can code", especially in AI era, but it doesn't mean they always should.
Once code in some area becomes quite complex, and has a long history of handling complicated issues, it is better to ask domain experts to look at it the issue first and provide their opinion
before doing any changes.
It will be no good spending time and effort to make changes in some sensitive area only to get them rejected by some domain expert who sees immediately that it breaks something unexpectedly or
doesn't correctly handle some nuances.
For example, I saw a difference of how the null share setting on transfer in progress was handled in 8.6.0, where it cleaned the abandoned connection later during removing easy handle from multi handle,
and the current code, but looking at the code, it is not clear to me why the same thing can't be done now - that's the reason why I suggested to ask an expert in this area to look at this issue.
> 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.
To be clear, I didn't mean to ask to fix the problem right away, and I just meant to ask an expert in this area who redesigned and reimplemented many parts of connection management and protocol handling to look at it and possibly provide an input if it can be fixed easily and maybe do the changes if it doesn't take a lot of efforts.
And I did it only because you mentioned that you might provide a better solution to it.
And yes, I am a commercial user, who uses libcurl on a very complicated streaming platform with 100M+ users in many countries.
We pay our price of using libcurl inside very complex multi-language frameworks and 3rd party code which we can't control and change,
and where even a small libcurl issue may have financial, reputational, human, and other serious consequences.
But we do our contribution to libcurl project in a way that we use libcurl in a wide range of scenarios with different ISPs, regions, CDNs, routers etc,
and diligently report issues which we think may affect other libcurl users as well.
It would be much easier for me not to report the issues like this one, just to avoid reminders that I am getting "a free lunch" from hard working volunteers,
and handle them somehow internally, but I think that it is worth effort to report them, because I don't think that our use cases are unique and some folks may step on such issues as well.
Hopefully, I was able to get some understanding.
Thanks,
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, July 2, 2026 11:25 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:
> 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-04