On 11/01/13 00:06, Amos Jeffries wrote:
Okay. So the source of the problem is that Squid thinks there is
something using the socket, but it never got into the tunnel code which
would have closed it?
Is the 403 message being generated inside Squid or by ICAP?
The 403 isn't generated by Squid. It can be generated in 2 different
ways (both result in the same problem):
1. The REQMOD ICAP server generates a "403 Forbidden" HTTP response.
2. The REQMOD ICAP server rewrites the HTTP request to GET from a local
webserver and that generates the "403 Forbidden" response.
In the case where the server generates the 403 and things hang it will
be because Squid is expecting a close to arrive from server or client.
Setting the "Connection: Close" HTTP header in the 403 response doesn't
help.
Once a tunnel is open and transmitting data it is up to those endpoints
to ensure keep-alive and other such details, although Squid applies a
timeout since last byte transferred.
Both the browser and the web server have closed the connection, but
squid isn't closing its side of the connection to the browser. Squid is
also not reading from the connection to the browser between the 403
response being sent and the browser dropping the connection (anything
the browser sends after the 403 just piles up in the socket's rx buffer).
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:steve@xxxxxxxxxxxx
Email: steve@xxxxxxxxxxxx
Phone: sip:steve@xxxxxxxxxxxx
Sales / enquiries contacts:
Email: sales@xxxxxxxxxxxx
Phone: +44-844-9791439 / sip:sales@xxxxxxxxxxxx
Support contacts:
Email: support@xxxxxxxxxxxx
Phone: +44-844-4844916 / sip:support@xxxxxxxxxxxx
