Re: [squid-users] CLOSE_WAIT

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
Received on Wed Jan 23 2013 - 05:12:19 MST