summaryrefslogtreecommitdiff
path: root/methods/file.cc
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2016-08-12 11:05:58 +0200
committerJulian Andres Klode <jak@debian.org>2016-10-05 21:53:38 +0200
commitdb19384200aa61930aa182e6b28f1635d4b69504 (patch)
treeaf1dc45b7daf68ee0ada15c9036d57e0819e2405 /methods/file.cc
parentc0475a2283d662a375295c1477d7193cef823832 (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 (cherry picked from commit 9714d522056e5256f5a2de587d88eba7cb3291c2)
Diffstat (limited to 'methods/file.cc')
0 files changed, 0 insertions, 0 deletions