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_at_opendium.com Email: steve_at_opendium.com Phone: sip:steve_at_opendium.com Sales / enquiries contacts: Email: sales_at_opendium.com Phone: +44-844-9791439 / sip:sales_at_opendium.com Support contacts: Email: support_at_opendium.com Phone: +44-844-4844916 / sip:support_at_opendium.comReceived on Fri Jan 11 2013 - 14:30:07 MST
This archive was generated by hypermail 2.2.0 : Sat Jan 12 2013 - 12:00:03 MST