Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.15 2020-12-27T08:58:19Z 2020-12-27T08:58:19Z Julian Andres Klode julian.klode@canonical.com 2020-12-27T08:53:26Z urn:sha1:4215b6b2ce64f7bd0988c63c8d7d3e34833ec813 2020-12-23T14:56:43Z Helge Kreutzmann debian@helgefjell.de 2020-12-23T14:56:43Z urn:sha1:46c8c73ae19b42928043a254688b2985320f5ceb Closes: #977938 2020-12-18T21:00:29Z Julian Andres Klode jak@debian.org 2020-12-18T21:00:29Z urn:sha1:06ec0067057e0578f3bc515f6a97d6a9d70824f6 Use encoded URIs in the acquire system See merge request apt-team/apt!139 2020-12-18T19:45:35Z David Kalnischkies david@kalnischkies.de 2020-07-10T18:19:31Z urn:sha1:a5859bafdaa6bcf12934d0fb1715a5940965e13a This commit potentially breaks code feeding apt an encoded URI using a method which does not get URIs send encoded. The webserverconfig requests in our tests are an example for this – but they only worked before if the server was expecting a double encoding as that was what was happening to an encoded URI: so unlikely to work as expected in practice. Now with the new methods we can drop this double encoding and rely on the URI being passed properly (and without modification) between the layers so that passing in encoded URIs should now work correctly. 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-12-18T18:31:19Z David Kalnischkies david@kalnischkies.de 2020-07-09T14:38:49Z urn:sha1:e6c55283d235aa9404395d30f2db891f36995c49 We do not deal a lot with URIs which need encoding, but then we do it is a pain that we store it decoded in the acquire system as it means we have to decode and reencode URIs eventually which is potentially giving us slightly different URIs. We see that in our own testing framework while setting up redirects as the config options are effectively double-encoded and decoded to pass them around successfully as otherwise %2f and / in an URI are treated the same. This commit adds the infrastructure for methods to opt into getting URIs send in encoded form (and returning them to us in encoded form, too) so that we eventually do not have to touch the URIs which is how it should be. This means though that we have to deal with methods who do not support this yet (aka: all at the moment) for which we decode and encode while communicating with them. 2020-12-18T18:02:05Z David Kalnischkies david@kalnischkies.de 2020-07-08T15:51:40Z urn:sha1:97be873d782c5e9aaa8b4f4f4e6e18805d0fa51c Our http method encodes the URI again which results in the double encoding we have unwrap in the webserver (we did already, but we skip the filename handling now which does the first decode). 2020-12-17T15:20:48Z Julian Andres Klode julian.klode@canonical.com 2020-12-17T15:17:12Z urn:sha1:ece7f5bb0afee0994a4fb4380e756ce725fe67a9 2020-12-15T21:13:12Z Julian Andres Klode julian.klode@canonical.com 2020-12-15T19:57:32Z urn:sha1:c6d40932f81edc656bbcc8dbd9d277aba543bc5b Unroll pkgCache::sHash 8 times and break up the dependency between the iterations by expanding the calculation H(n) = 33 * H(n-1) + c 8 times rather than performing it 8 times. This seems to yield about a 0.4% performance improvement. I tried unrolling 4 and 2 bytes as well, those only having 3 ifs at the end rather than 1 small loop; but that was actually slower - potentially the code got to large and the cache went bonkers. I also tried unrolling 4 times instead of 8, thinking that smaller code might yield better results overall then, but that was slower as well. 2020-12-15T13:07:59Z Julian Andres Klode julian.klode@canonical.com 2020-12-15T13:07:59Z urn:sha1:5afd3ff6834430bb252ce5a37686bf1481f7c590