Re: Occasional Zero Sized Reply error with 2.6

tor 2006-06-29 klockan 10:40 -0300 skrev Gonzalo Arana:

> ...
> } else if (flag == COMM_OK && len == 0 && !flags.headers_parsed) {
> fwd->fail(errorCon(ERR_ZERO_SIZE_OBJECT, HTTP_BAD_GATEWAY));
[..]
> } else if (flag == COMM_OK && len == 0) {
[..]
> 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();

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

Yes.. to handle broken servers not sending complete headers.

> 1) A 'zero size object' is a good reply in this case?

Only if no data at all has been received I think. Maybe not if partial
headers have been received. But it's a border 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.

Yes, but this is handled in the FwdState. Or at least should be...
retrying the request on certain classes of errors. This is also why
local errors is not pushed to the StoreEntry by the protocol handlers
but merely registered with the fwdstate..

> 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.

Ok. So the retry logic has gone defunct, pretty much like the abort
logic had...

> 4) How to react if server closes connection before we even get reply
> headers?

If it's the first request on a new connection a ERR_ZERO_SIZED_REPLY.
Else FwdState should retry the request on a new connection (preferably a
brand new connection to not run into the same issue again).

All the logics for doing this is there already. The question is why it
doesn't get triggered. See FwdState::serverClosed.

> 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).

Unfortunately not that I know of.

Regards
Henrik