<div dir="ltr">Hello Squid Developers.<br><br>I'm a software engineer.<br><br>My team uses Squid with an ICAP server. We have noticed that Squid leaks file descriptor and memory when (reqmod) ICAP server replies with http "403 Forbidden" on http CONNECT request.<br><br>Here is a step-by-step description of the problematic scenario:<br>- An http client connects to Squid and sends CONNECT request (for example, "curl -q -x <a href="http://127.0.0.1:3128">http://127.0.0.1:3128</a> <a href="https://example.com">https://example.com</a>");<br>- Squid sends CONNECT request to the (reqmod) ICAP server;<br>- ICAP server sends back a "403 Forbidden" http response;<br>- Squid sends "403 Forbidden" http response to the http client (in the example above, curl reports "Received HTTP code 403 from proxy after CONNECT");<br>- Squid writes to cache.log a message like "kick abandoning <....>";<br>- Squid does not close the file descriptor used for http client connection.<br><br>Those file descriptors and associated memory do pile up. For instance, after 200.000 forbidden requests squid (built from git master) has ~200.000 open descriptors and consumes ~4 Gb RAM. On production deployment with 1000+ users it takes less than a day for Squid to eat out all available RAM.<br><br>It seems that the same problem was previously reported here: <a href="http://www.squid-cache.org/mail-archive/squid-users/201301/0096.html">http://www.squid-cache.org/mail-archive/squid-users/201301/0096.html</a><br><br>Message "kick abandoning <....>" comes from ConnStateData::kick() in client_side.cc. Closing clientConnection right after "debugs(<....>abandoning<....>)" fixes the leak.<br><br>Is it ok to always close() clientConnection when "abandoning" thing happens? Are there any known scenarios where this close() would be inappropriate?<br><br>Could you please give me some advice on a better/proper fix, if close() at "abandoning" time is wrong?<br></div>