On 22/01/2013 3:31 a.m., Steve Hill wrote:
On 11.01.13 00:06, Amos Jeffries wrote:So it seems apparent that after Squid delivers the clear-text response, it abandons the socket but never closes it. From looking in the source, this is client_side.cc, and it has a comment: // XXX: Can this happen? CONNECT tunnels have deferredRequest set. It looks to me as if the (conn->flags.readMore) section above should be the bit being executed, although I don't quite understand deferred requests. In either case, it seems like we should close the socket if it ever gets abandoned?Calling conn->clientConnection->close() from else part where the connection is abandoned seems the right thing to do. Is there any situation where closing the connection when it is abandoned is the wrong thing to do?
IIRC we tried that but it resulted in early cloure of CONNECT tunnels and a few other bad side effects on the tunnelled traffic. Due to the way tunnel.cc and client_side.cc code interacts (badly) the client-side code cannot know whether the tunnel is still operating or has data buffered when it gets to the point of emitting that message.
However, since the CONNECT and the response were both served with a "Connection: keep-alive" header, it seems that readMore should really be true at this point anyway. clientProcessRequest() explicitly sets readMore = false for CONNECT requests, so I don't understand how Squid handles keep-alive CONNECT tunnels?
Keep-alive on CONNECT only works when the response is an error page produced by Squid, or a 30x redirection produced by Squid. Anything else is just "binary" tunnelled octets as far a the proxy Squid is concerned. Since that Squid cannot know how many octets will be transferred (chunked encoding and Content-Length not supportd yet on CONNECT) the only way to terminate the tunnel is closure.
Ideally I would like chunked encoding to be supported on CONNECT requests, but do not have the time to see it developed.
Amos
