curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. 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 himself.

Re: sharing cookies … bug?

From: Felipe Gasper via curl-library <>
Date: Thu, 5 Mar 2020 11:06:32 -0500

> On Mar 5, 2020, at 10:51 AM, Daniel Stenberg <> wrote:
> Here to just enable cookie-sharing but you never enable the cookie engine for the second handle so while the cookies are known to the handle, it hasn't been told to use them. This can probably be fixed by adding:
> curl_easy_setopt(easy2, CURLOPT_COOKIEFILE, "");
> The reason this change is necessary, is because the previous behavior was actually a bug that could lead to "accidental" use of cookies in the second request. That isses was brought in #4429 back in September 2019, the fix landed in 7.67.0:

OK, thank you!

I saw that issue and assumed it might be related, but I didn’t try CURLOPT_COOKIEFILE on both easy objects because I thought that CURLOPT_COOKIEFILE/"" initialized a shared “cookie jar” rather than individual easy objects’ cookie engines. So it seemed like setting CURLOPT_COOKIEFILE/"" on easy2 would _clear_ the cookies.

Did that change not break applications out in the wild? It seems like it would have; I see the same auto-cookies behavior in 7.29 (CentOS 7) and 7.54 (macOS Mojave).

Would a PR to clarify the documentation on this point be acceptable? e.g., in curl_share_setopt(3)’s description of CURL_LOCK_DATA_COOKIE, something like:

Prior to 7.67, designating a cookie-sharing share object on an easy automatically enabled that easy object’s cookie engine. As of curl 7.67, though, for an easy object to use a cookie share it is necessary to explicitly initialize that easy object’s cookie engine, e.g., curl_easy_setopt(easy, CURLOPT_COOKIEFILE, "").
Regardless, thank you again!
Received on 2020-03-05