On Fri, Aug 14, 2009 at 01:56:11PM -0400, Daniel Richard G. wrote:
> I've investigated this bug further, and found the problem. Here is a
> walk-through of it, in apt-cacher 1.6.8:
>
> 1. First, in the handle_connection() subroutine (line 243), you read in
> the request. apt-get(8) typically uses HTTP Keep-Alive for efficiency
> (i.e. download multiple files in one TCP connection), so when you're
> done with the CLIENTLINE: loop and have read in the first request, a
> handful of subsequent requests remain in the buffer (see @reqLineBuf,
> and the getRequestLine() subroutine as well) waiting to be serviced.
>
> 2. This normally works well. A file is requested, the file gets sent,
> apt-cacher loops back to the top of the REQUEST: loop (line 338), and
> proceeds to service the next request in the buffer.
>
> 3. When a Translation-en_US* file is requested, apt-cacher sees that it
> doesn't have this file, and proceeds to request it from the upstream
> repository. The repository returns 404, because---as we already
> know---
> Translation-en_US* files don't exist.
>
> 4. But here's what happens: Look in return_file(), line 839. Here, it
> checks the HTTP status code ($code) from the upstream server, and
> because it's 404, and $concloseflag is false, it sets
> $concloseflag to true.
>
> 5. This has effect way back up in handle_connection(), line 339. The
> loop condition is no longer true, so it exits. No further requests
> are read in, and the connection is subsequently closed.
>
> 6. Just one small problem---there are still a number of outstanding
> requests in @reqLineBuf waiting to be serviced! The "Connection reset
> by peer" error message reflects apt-get(8)'s confusion at seeing the
> connection closed prematurely.
>
>
> The following modification narrowly fixes the behavior as described in
> the original bug report:
>
> --- apt-cacher-1.6.8/apt-cacher2 2009-02-22 15:30:20.000000000
> -0500
> +++ apt-cacher-1.6.8/apt-cacher2.fixed 2009-08-14 13:30:37.000000000
> -0400
> @@ -836,7 +836,7 @@
>
> # keep alive or not?
> # If error, force close
> - if ($code!=200 && !$concloseflag) {
> + if ($code!=200 && $code!=404 && !$concloseflag) {
> debug_message("Got $code error. Going to close connection.");
> $concloseflag=1;
> }
>
> More generally, I believe this very notion of closing the (client)
> connection on an upstream server error is faulty---a client making use
> of Keep-Alive will expect the HTTP error header to be returned, and then
> further requests to be fulfilled on the same connection. Maybe there are
> some instances where you do want to drop the connection immediately, but
> I can't think offhand of any problem [that is specific to the upstream
> server] that should trigger this.
OK. Thanks for this. I have been unable to reproduce.
Can you fix it by observing the Keep-Alive?
I looked through the changelog, and the behaviour to ignore it in the
case of 404 errors comes from bugs #322299 and #384210.
Mark
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
