Re: cacerts download is a bit sideways on Ubuntu

2021-01-10 Thread Jeffrey Walton via curl-library
On Mon, Jan 11, 2021 at 2:35 AM Daniel Stenberg wrote: > > On Mon, 11 Jan 2021, Jeffrey Walton via curl-library wrote: > > > $ lsb_release -a > > Distributor ID:Ubuntu > > Description:Ubuntu 20.04.1 LTS > > Release:20.04 > > Codename:focal > > > > $ command -v wget > >

Re: cacerts download is a bit sideways on Ubuntu

2021-01-10 Thread Daniel Stenberg via curl-library
On Mon, 11 Jan 2021, Jeffrey Walton via curl-library wrote: $ lsb_release -a Distributor ID:Ubuntu Description:Ubuntu 20.04.1 LTS Release:20.04 Codename:focal $ command -v wget /usr/bin/wget $ wget -O cacert.pem 'https://curl.haxx.se/ca/cacert.pem' Unable to locally verify

cacerts download is a bit sideways on Ubuntu

2021-01-10 Thread Jeffrey Walton via curl-library
Hi Everyone/Daniel, $ lsb_release -a Distributor ID:Ubuntu Description:Ubuntu 20.04.1 LTS Release:20.04 Codename:focal $ command -v wget /usr/bin/wget $ wget -O cacert.pem 'https://curl.haxx.se/ca/cacert.pem' --2021-01-11 02:09:02-- https://curl.haxx.se/ca/cacert.pem Resolving

Re: Test 1061 flaky when run without valgrind

2021-01-10 Thread Ray Satiro via curl-library
On 1/10/2021 5:33 PM, Daniel Stenberg via curl-library wrote: On Sun, 10 Jan 2021, Fabian Keil via curl-library wrote: The attached patch seems to work around the problem. Busy-looping probably isn't the right solution, though. Yeah, that's just not the right fix. When the code returns

Re: conn.data considered bad

2021-01-10 Thread Daniel Stenberg via curl-library
On Sun, 10 Jan 2021, Patrick Monnerat wrote: Not for me with NSS/3.60. Test 300 works fine here. Fedora 33 stock nss 3.59.0 here. Fired up a VM with an older distro. Current curl master with NSS/3.26.2 - also ran fine. (except that unit test 1621 fails to build there) Not dimissing your

Re: conn.data considered bad

2021-01-10 Thread Patrick Monnerat via curl-library
On 1/10/21 10:57 PM, Daniel Stenberg wrote: On Sun, 10 Jan 2021, Patrick Monnerat wrote: Plase note that nss seems cursed (even in the master branch): test suite gives valgrind errors and test 300 never finishes. Not for me with NSS/3.60. Test 300 works fine here. Fedora 33 stock nss

Re: Test 1061 flaky when run without valgrind

2021-01-10 Thread Daniel Stenberg via curl-library
On Sun, 10 Jan 2021, Fabian Keil via curl-library wrote: The attached patch seems to work around the problem. Busy-looping probably isn't the right solution, though. Yeah, that's just not the right fix. When the code returns there (http_proxy.c line 346) due to CURLE_AGAIN having been

Re: Setting connection timeout per host?

2021-01-10 Thread Daniel Stenberg via curl-library
On Sun, 10 Jan 2021, Midnight Wonderer wrote: Thanks for explaining! This is potentially affecting most HTTP-based services in existence. But client retry is not practical, mostly because there is no standard for it. Some clients took, like, a minute to try the next IP address. Take curl as

Re: conn.data considered bad

2021-01-10 Thread Daniel Stenberg via curl-library
On Sun, 10 Jan 2021, Patrick Monnerat wrote: Plase note that nss seems cursed (even in the master branch): test suite gives valgrind errors and test 300 never finishes. Not for me with NSS/3.60. Test 300 works fine here. -- / daniel.haxx.se | Commercial curl support up to 24x7 is

Re: Test 1061 flaky when run without valgrind

2021-01-10 Thread Fabian Keil via curl-library
Fabian Keil via curl-library wrote on 2021-01-09: > Fabian Keil via curl-library wrote on 2021-01-08: > > > using a curl binary built from git master 060658f634, test 1061 > > works reliably for me when valgrind is being used but is flaky > > without it: [...] > The problem seems to be that

Re: conn.data considered bad

2021-01-10 Thread Patrick Monnerat via curl-library
On 1/10/21 5:59 PM, Daniel Stenberg wrote: On Sun, 10 Jan 2021, Patrick Monnerat wrote: Could be turned at first as: void abcd(struct Curl_easy *data) abcd(conn->data); Sure it can, and if you can come up with a way where that helps then good for you. In my head that's just an

Re: conn.data considered bad

2021-01-10 Thread Daniel Stenberg via curl-library
On Sun, 10 Jan 2021, Patrick Monnerat wrote: Could be turned at first as: void abcd(struct Curl_easy *data) abcd(conn->data); Sure it can, and if you can come up with a way where that helps then good for you. In my head that's just an intermediate step that I don't think is necessary to

Re: Setting connection timeout per host?

2021-01-10 Thread Midnight Wonderer via curl-library
On Sun, 10 Jan 2021 at 20:44, Daniel Stenberg wrote: > I would rather we focued on what exactly the problem and use case you have > with the existing algoritm is that makes you not able to just perhaps extend > the timeout a little? Good point! To add some background: As we all know, if you

Re: conn.data considered bad

2021-01-10 Thread Patrick Monnerat via curl-library
On 1/10/21 2:32 PM, Daniel Stenberg wrote: On Sun, 10 Jan 2021, Patrick Monnerat via curl-library wrote: Considering the large number of references, I would suggest starting to fix this "bottom up" by smaller commits rather than having a big patch, even if it increases the reference count at

Re: Setting connection timeout per host?

2021-01-10 Thread Daniel Stenberg via curl-library
On Sun, 10 Jan 2021, Midnight Wonderer wrote: Realistically speaking, anyone who put 20 addresses for a hostname doesn't expect the client to try all 20 addresses; This can be made an option with a sane default. (like 4, or some number acquirable via statistic mean, or simply turn off) It

Re: conn.data considered bad

2021-01-10 Thread Daniel Stenberg via curl-library
On Sun, 10 Jan 2021, Patrick Monnerat via curl-library wrote: Considering the large number of references, I would suggest starting to fix this "bottom up" by smaller commits rather than having a big patch, even if it increases the reference count at first while the work is not complete.

Re: conn.data considered bad

2021-01-10 Thread Patrick Monnerat via curl-library
On 1/8/21 3:51 PM, Daniel Stenberg via curl-library wrote: Hi all, Here's something that's been itching in me for a long time. Something I've even (twice!) tried to fix. Both times my patch ended up so huge and complicated for me that I had to give it and postpone the idea. Put shortly: