Op 17-11-10 23:54, Stefan Fritsch schreef: > It turns out the problem is not in packet 19, which is well after the > 90 second delay, but in packet 6, which is the last data received > before the delay, and the last data on that connection.
Ah, I forgot to look at the time stamps. The problem must indeed be before it. > The second response is a 404 which should have a body. But apt-cacher- > ng does not include a body, therefore it must send a "Content-Length: > 0" header. Or, seen the other way round, since this response does not > include a Content-Length header, aptitude must treat all data to the > end of the connection as body for this responce, per RFC 2616 4.4. > Therefore aptitude has to wait until apt-cacher-ng closes the > connection, which apt-cacher-ng does after 90 seconds. This is what > makes aptitude seem to hang. That does explain the delay. The problem is that it seemed to hang on the local repository, but I was mistaken about that. The error was: http://localhost sid/i386/ Release.gpg [ERROR] Error reading from server. Remote end closed connection [IP: ::1 3142] "sid/i386" only appears for the local repository in sources.list, which is what made me think it must be there. However, the IP clearly shows that this is the link with apt-cacher-ng, not with localhost:80/~shevek. > HTTP/1.1 404 Not Found > Date: Sun Nov 14 07:15:55 2010 > Server: Debian Apt-Cacher NG/0.5.10 > X-Original-Source: > http://ftp.debian.org/debian/dists/unstable/main/i18n/Translation- > en.bz2 > Connection: Keep-Alive I thought it was my inexperience with http that made me unable to see where the packet ended, but as I now understand it, aptitude doesn't see it either. :-) > So my initial analysis is incorrect and there is actually a bug in > apt-cacher-ng. Reassigning. Thanks for analyzing this! Bas
signature.asc
Description: OpenPGP digital signature
