Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.17 2020-12-18T18:31:19Z 2020-12-18T18:31:19Z David Kalnischkies david@kalnischkies.de 2020-07-09T22:02:25Z urn:sha1:97d6c3b2d05fe0d965657197adf56cc78f9edf81 Every method opts in to getting the encoded URI passed along while keeping compat in case we are operated by an older acquire system. Effectively this is just a change for the http-based methods as the others just decode the URI as they work with files directly. 2020-08-10T09:39:30Z Julian Andres Klode julian.klode@canonical.com 2020-08-10T09:39:30Z urn:sha1:fa375493c5a4ed9c10d4e5257ac82c6e687862d3 While we fixed the infinite retrying earlier, we still have problems if we retry in the middle of a transfer, we might end up resuming downloads that are already done and read more than we should (removing the IsOpen() check so that it always retries makes test-ubuntu-bug-1098738-apt-get-source-md5sum fail with wrong file sizes). I think the retrying was added to fixup pipelining messups, but we have better solutions now, so let's get rid of it, until we have implemented this properly. 2020-08-05T12:15:49Z Julian Andres Klode julian.klode@canonical.com 2020-08-05T12:14:19Z urn:sha1:4b439208203cd584e158fd240a3a4a72d1248099 When we failed after a retry, we only communicated failure as transient, but this seems wrong, especially given that the code now always triggers a retry when Die() is called, as Die() closes the server fd. Instead, remove the error handling in that code path, and reuse the existing fatal-ish error code handling path. 2020-08-05T09:08:16Z Julian Andres Klode julian.klode@canonical.com 2020-08-05T09:04:45Z urn:sha1:ded246bb61b9b0f4ca658be45c1691844e1dc122 If there was a transient error and the server fd was closed, the code would infinitely retry - it never reached FailCounter >= 2 because it falls through to the end of the loop, which sets FailCounter = 0. Add a continue just like the DNS rotation code has, so that the retry actually fails after 2 attempts. Also rework the error logic to forward the actual error message. 2019-07-08T13:51:17Z David Kalnischkies david@kalnischkies.de 2019-07-08T13:48:59Z urn:sha1:2b734a7ec429825c7007c1093883229e069d36c7 Reported-By: cppcheck 2019-06-17T16:28:52Z Julian Andres Klode julian.klode@canonical.com 2019-06-17T16:28:52Z urn:sha1:97553e635d2265ec4aad96b00b1fd72d98437f15 We are converting to std::string anyway by passing to istringstream, and this removes the need for .c_str() in callers. 2019-04-30T15:43:56Z Julian Andres Klode julian.klode@canonical.com 2019-04-30T10:32:54Z urn:sha1:af74a9e2d55d6a9532eb3fbb9b96c65b7ddc1e4d This needs a fair amount of changes elsewhere in the code, hence this is separate from the previous commits. 2018-09-18T14:07:24Z Julian Andres Klode julian.klode@canonical.com 2018-08-31T14:07:07Z urn:sha1:df696650b7a8c58bbd92e0e1619e956f21010a96 It is perfectly valid behavior for a server to respond with Connection: close eventually, even when pipelining. Turning off pipelining due to that is wrong. For example, some Ubuntu mirrors close the connection after 101 requests. If I have more packages to install, only the first 101 would benefit from pipelining. This commit introduces a new check to only turn of pipelining for future connections if the pipeline for this connection did not have 3 successful fetches before, that should work quite well to detect broken server/proxy combinations like in bug 832113. 2018-05-24T12:31:31Z Julian Andres Klode julian.klode@canonical.com 2018-05-24T12:31:31Z urn:sha1:329a4a6159f1972ff5ec7bc2db26430f26dc61f3 120s is an insanely high default time out, lower it to 30s to make things a bit nicer. 2018-05-11T12:51:50Z David Kalnischkies david@kalnischkies.de 2018-05-11T12:51:50Z urn:sha1:b0283a5aeee428c9f2567b81ae78c9da68f6f4af This shouldn't make a practical difference for most people, but for edge cases it avoids DNS lookups and additionally prevents us from perfoming unneeded SRV requests, too.