Re: sharing cookies … bug?
On 3/5/2020 11:06 AM, Felipe Gasper via curl-library wrote: 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, ""). --- It's not necessary to document the bug but I've submitted a PR to clarify the documentation. [1] Thanks [1]: https://github.com/curl/curl/pull/5048 --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: sharing cookies … bug?
FWIW, here is some in-the-wild code that the 7.67 cookie-share change broke: https://github.com/sparky/perl-Net-Curl/blob/master/examples/02-multi-simple.pl -FG > On Mar 5, 2020, at 11:06 AM, Felipe Gasper via curl-library > wrote: > > > >> 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: >> >> 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 --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: sharing cookies … bug?
> 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: > > 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
Re: sharing cookies … bug?
On Thu, 5 Mar 2020, Felipe Gasper via curl-library wrote: Hi Felipe! I think I know what the problems is. SHARE_SETOPT( easy1, share ); curl_easy_setopt(easy1, CURLOPT_COOKIEFILE, ""); Here you enable cookie-sharing and enables the cookie engine on the easy1 handle. SHARE_SETOPT( easy2, share ); curl_easy_setopt( easy2, CURLOPT_URL, "http://www.google.com/search?q=curl; ); 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 -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
sharing cookies … bug?
I’ve got the following sample code:
=
#include
#include
#define SHARE_SETOPT(easy, value) curl_easy_setopt(easy, CURLOPT_SHARE, value)
int main() {
fprintf(stderr, "Cookie version - %s\n", curl_version());
CURLSH* share = curl_share_init();
curl_share_setopt(share, CURLSHOPT_SHARE, CURL_LOCK_DATA_COOKIE);
CURL* easy1 = curl_easy_init();
curl_easy_setopt( easy1, CURLOPT_VERBOSE, 1 );
SHARE_SETOPT( easy1, share );
curl_easy_setopt(easy1, CURLOPT_COOKIEFILE, "");
curl_easy_setopt( easy1, CURLOPT_URL, "http://www.google.com/search?q=perl;
);
curl_easy_perform(easy1);
CURL* easy2 = curl_easy_init();
curl_easy_setopt( easy2, CURLOPT_VERBOSE, 1 );
SHARE_SETOPT( easy2, share );
curl_easy_setopt( easy2, CURLOPT_URL, "http://www.google.com/search?q=curl;
);
curl_easy_perform(easy2);
return 0;
}
=
… which I compile with this statement:
gcc -L/Users/felipe/mycurl/lib -I/Users/felipe/code/curl/include/curl -o
curl_google curl_google.c -lcurl && ./curl_google 2>&1 | grep Cookie | grep -v
Set-Cookie
… and get:
Cookie version - libcurl/7.69.0-DEV OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.3.0
libpsl/0.21.0 (+libidn2/2.1.1)
Note that there’s no “Cookie:” header being sent.
Am I “holding it wrong”, or is this a bug? I see the same behavior in 7.68, but
if I compile against an older libcurl, I get what I expect:
Cookie version - libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1
Cookie: CGIC=IgMqLyo;
NID=199=K3m9Ak7ESVyswq45PmirFnDu74CgtqWd-vbDWY2FTfA4JySBSGXzv0QL84nZpOVMmpUZ26y-1C3Sdi03-TMo3t1YghWTeALjbHllRX6LgZiilNOVUtLAezy_fLXAscQ4JOZvO34yGmvTPfNB18My4g-Wn2MYUnL2Fo6VoTQhjYA
This is all under macOS.
Thank you!
-FG
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
