Closed badp closed 6 years ago
I've had success with:
$ cat /etc/apt/apt.conf.d/80http
Acquire::http::No-Cache true;
Acquire::http::Pipeline-Depth 0;
for this sort of thing in the past.
This probably has the same root cause as #13 , and I like @eythian's suggestion. Wikipedia says that on http < v2, http pipelining is barely used and often not properly implemented. That's probably also true for the monkey-patched twisted
code that pac4cli
uses.
In general, pac4cli
's http handling is poorly tested because most traffic goes over https (so proxy CONNECT) these days. That also means that I haven't dared put the proxy configuration for Apt in the debian package. (Another reason for that is that it would mean a pac4cli
breakage means we can't update pac4cli
to fix it.)
as an addendum, it seems that the Acquire::http::No-Cache true;
directive is unnecessary (I'll amend this comment if reality proves me wrong).
That may well be correct, I remember it being a "good offense is the best defence" type solution to defend against proxy weirdness.
On 10 August 2018 17:31:38 CEST, Santi notifications@github.com wrote:
as an addendum, it seems that the
Acquire::http::No-Cache true;
directive is unnecessary (I'll amend this comment if reality proves me wrong).-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/tkluck/pac4cli/issues/32#issuecomment-412119121
-> #37
I have the following error when updating my repositories through pac4cli, but not when I instruct apt to go directly through the proxy:
I cannot reproduce the issue from the command line:
The downloaded files are binary-equal.
This doesn't just happen for apt update. apt-upgrade also failed on, say, this package:
I remember having a similar issue with my workplace's squid proxies as well, but the newer proxies don't seem to exhibit this issue. The only resolution at the time, IIRC, was not using the proxies...