On Wed, Jul 27, 2016 at 08:16:03AM +0200, nice sw123 wrote:
> If I comment out proxy settings...
>
> > # Acquire::http::Pipeline-Depth 0;
> > # Acquire::https::Pipeline-Depth 0;
> > # Acquire::http::No-Cache true;
> > # Acquire::https::No-Cache true;
>
> ... then I sometimes get a message:
> Automatically disabled Acquire::http::PipelineDepth due to incorrect
> response from server/proxy. (man 5 apt.conf).
>
> See
> https://github.com/Debian/apt/blob/cc0a4/methods/server.cc#L642
>
> Is the parameter
> Acquire::http::PipelineDepth or
> Acquire::http::Pipeline-Depth
> ??
The correct option is with '-', the message is incorrect… (fixed in
git), thanks for noticing!
I will respond to your first proxy first as I was mostly done with the
mail before I saw your second and then got interupted and now it was
lying around in the draft folder for a bit already…:
The issue itself is bit mysterious. The debug tells me few things: None
of it is very positive in terms of your proxy, so if you have the
option, I would recommend using another.
Your proxy seems to close connections at times even through its supposed
to keep the connection open; based on the Proxy-Connection header it
sends I wonder if we are talking about a chain of proxies (as that
header is non-standard, related to HTTP/1.0 and even back then was
supposed to be used by clients talking to a proxy, not by a proxy
replying to a client) further elevated by the appearance of a Keep-Alive
field which is also not really HTTP/1.1 material although apt request
talking in HTTP/1.1 and the proxy replies with HTTP/1.1.
Something about that connection closing seems to "trick" apt into
sending more requests than it should. I fail to see which path that
takes, but its the only explanation I can come up with based on the
debug messages and the code doing the fetches – the later I rewrote in
the 1.3 series and careful rereading suggests that the old version would
not perform a request if the limit is reached, while the new version
always makes at least one request with the assumption that it is called
only if at least one request should be made ("fixed" in git).
Looking at your second proxy now I am pretty much convienced we are
talking about a chain of proxies here as it sports the same strange
header fields and somehow I believe these proxies don't mix well.
The second proxy is one which always closes the connection after
answering a request – which isn't very efficient, but at least the proxy
is upfront about it. The interaction looks rather "normal" althrough
I haven't much sympathy for mirrors returning 404 for files which should
be there… switch to another perhaps?
Based on this report and #831762 I made a bunch of commits which for
this report I am not entirely sure will fix the problem, but I at least
have some hope for it. We will see with the next upload I guess. In the
meantime: Thanks for your input so far!
Best regards
David Kalnischkies
P.S.: You can attach files to mails sent to the bugreport as well
instead of inlining the content; you don't have to get through the
trouble of sending me a dedicated mail with the logs as attachment.
Attachment:
signature.asc
Description: PGP signature