Re: Occasional Zero Sized Reply error with 2.6

I've noticed this on squid3 as well. While trying to hunt this, I've
found this in
HttpStateData::readReply:
...
} else if (flag == COMM_OK && len == 0 && !flags.headers_parsed) {
        fwd->fail(errorCon(ERR_ZERO_SIZE_OBJECT, HTTP_BAD_GATEWAY));
        eof = 1;
        flags.do_next_read = 0;
        comm_close(fd);
} else if (flag == COMM_OK && len == 0) {
        /* Connection closed; retrieval done. */
        eof = 1;

        if (!flags.headers_parsed)
            /*
            * When we called processReplyHeader() before, we
            * didn't find the end of headers, but now we are
            * definately at EOF, so we want to process the reply
            * headers.
             */
            processReplyHeader();
        else

Some thoughts:

0) The 'if (!flags.headers_parsed)....' is dead code. Any ideas what
was the original idea of this?

1) A 'zero size object' is a good reply in this case? if server
closed the connection before we even got reply headers, this could
mean that server actually closed connection before it got our last
request.

2) In fact, sniffing with ethereal I've 'verified' this. Not a
foolproff check, but I have about 220ms of RTT to osnews.com, and you
can see that between packets 88 & 89 of attached pcap file there are
about 50ms. This means that: server closed connection, my squid3
sends the request, my squid3 receives the FIN packet for the very same
TCP connection.

3) How to reproduce: As Guido pointed out, this can be reproduced
(with some effort) while navigating through osnews.com. Server-side
connection keepalive timeout timing makes it difficult to reproduce.

4) How to react if server closes connection before we even get reply
headers? I propose to retry the same request (if method is GET, no
authentication data present in request, and possible many other
conditions).

I believe it would be great if we could check last TCP ACK value from
server-side when read(2) returns 0. This way, we could know if server
actually got the request and only retry if it didn't. Is there any
way to read that? tcp(7) manpage does not show anything useful :( (at
least on Linux).

Regards,

-- 
Gonzalo A. Arana