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: Timer callback called excessively?!
Den tors 5 mars 2020 16:14Daniel Stenberg skrev: > On Mon, 2 Mar 2020, Andreas Bengtsson via curl-library wrote: > > > I am using libcurl 7.68.0 and i am experiencing a strange issue with the > > timer function callback being called a lot during download of a file. > > Do you know if this is any difference in behavior compared to previous > versions? > Yes, we moved from 7.58.0, and there we didn't see this behaviour. No change in our code except moving from libcurl 7.58.0 included in Android to prebuilt 7.68.0. > > > When i call curl_multi_socket_action, i always get a callback on the > timer > > function, even if the timer did not elapse. While downloading the timer > > callback is called approx. 3000 times / sec with the timeout set to > > 1000ms... > > Ugh. Sounds like a terrible bug. Can you help us and write up a test > program > that reproduces the problem? > I can try... > > > Am i missing something crucial here that makes my implementation of > libcurl > > trigger the timer callback that often? > > It should only call the timer callback if it needs to update the timer and > it > really shouldn't be possible to update it that often... > > -- > > / daniel.haxx.se | Commercial curl support up to 24x7 is available! >| Private help, bug fixes, support, ports, new features >| https://www.wolfssl.com/contact/ Regards Andreas > > --- 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
Re: CURLOPT_POST with no CURLOPT_POSTFIELDS
On Wed, 4 Mar 2020, Jason Proctor via curl-library wrote: The issue is that if you specify CURLOPT_POST but don't specify CURLOPT_POSTFIELDS, then the library sticks in sending mode and doesn't call the header or write callbacks, despite the fact that the server has happily sent a response. Setting CURLOPT_POSTFIELDS to the empty string results in the correct behaviour. That's not expected behavior nor does it match what existing libcurl tests verify that works. For example in test 1514: https://github.com/curl/curl/blob/master/tests/libtest/lib1514.c Can you provide a test code that reproduces this? -- / 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
Re: Timer callback called excessively?!
On Mon, 2 Mar 2020, Andreas Bengtsson via curl-library wrote: I am using libcurl 7.68.0 and i am experiencing a strange issue with the timer function callback being called a lot during download of a file. Do you know if this is any difference in behavior compared to previous versions? When i call curl_multi_socket_action, i always get a callback on the timer function, even if the timer did not elapse. While downloading the timer callback is called approx. 3000 times / sec with the timeout set to 1000ms... Ugh. Sounds like a terrible bug. Can you help us and write up a test program that reproduces the problem? Am i missing something crucial here that makes my implementation of libcurl trigger the timer callback that often? It should only call the timer callback if it needs to update the timer and it really shouldn't be possible to update it that often... -- / 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
