summaryrefslogtreecommitdiff
path: root/cmdline/apt-report-mirror-failure
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2016-08-12 11:05:58 +0200
committerDavid Kalnischkies <david@kalnischkies.de>2016-08-16 19:20:28 +0200
commit9714d522056e5256f5a2de587d88eba7cb3291c2 (patch)
treea824abdbd23799b688fcb453bc5de2d67403ce0f /cmdline/apt-report-mirror-failure
parentd94b1d80d8326334d17f6a43061368e783b8e0aa (diff)
don't try pipelining if server closes connections
If a server closes a connection after sending us a file that tends to mean that its a type of server who always closes the connection – it is therefore relatively pointless to try pipelining with it even if it isn't a problem by itself: apt is just restarting the pipeline each time after it got served one file and the connection is closed. The problem starts if one or more proxies are between the server and apt and they disagree about how the connection should be as in the bugreporters case where the responses apt gets contain both Keep-Alive and Proxy-Connection headers (which apt both ignores) indicating a proxy is trying to keep a connection open while the response also contains "Connection: close" indicating the opposite which apt understands and respects as it is required to do. We avoid stepping into this abyss by not performing pipelining anymore if we got a respond with the indication to close connection if the response was otherwise a success – error messages are sent by some servers via this method as their pages tend to be created dynamically and hence their size isn't known a priori to them. Closes: #832113
Diffstat (limited to 'cmdline/apt-report-mirror-failure')
0 files changed, 0 insertions, 0 deletions