> On Mar 5, 2020, at 10:51 AM, Daniel Stenberg <dan...@haxx.se> 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: > > https://github.com/curl/curl/issues/4429
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! -FG ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
