[squid-users] Connection occasionally not ending after adapting response with ICAP

[Alex Rousskov]

On 12/30/20 10:40 AM, Moti Berger wrote:

>>>> I don't see the "0 CR LF CR LF" at all, not only for those URLs that
> cause the curl to hang.

I suspect that none of those ICAP responses have HTTP bodies. An ICAP
response without an HTTP body, in itself, is not a bug, but it probably
explains the problem you are having. See below for more details.


> I'm attaching a tcpdump file.

FWIW, my wireshark cannot read your packet capture file: "The capture
file appears to be damaged or corrupt. File has 1852785440-byte packet,
bigger than maximum of 262144". In the future, you should compress such
files before sharing them via email.

However, looking at the ASCII parts of that capture file, I probably see
the likely culprit. The ICAP response below can be considered invalid
or, at least, rather difficult to handle correctly:

> ICAP/1.0 200 OK
> ISTag: "tmrCy72n1Qgsn1mxBipIb4jdEYdce3"
> Date: Wed, 30 Dec 2020 15:07:52 GMT
> Server: BaseICAP/1.0 Python/3.6.12
> Encapsulated: res-hdr=0, null-body=140
> 
> HTTP/1.1 307 Temporary Redirect
> location: http://www.redirect.url
> Cache-Control: no-cache, no-store, must-revalidate
> Pragma: no-cache


The HTTP 307 response header sent by the ICAP server promises an HTTP
response body (per HTTP rules), but the ICAP response has no HTTP body
(per the "null-body" value in the Encapsulated header).

I do not remember what Squid does in this problematic case, but I
suspect the outcome is a stuck HTTP transaction.

You should fix the ICAP service to either stop promising an HTTP
response body or provide one. The easiest (but ugly) fix may be to add
Content-Length:0 to the HTTP header returned by the ICAP service. A
better fix would be to include a real body that explains why the request
was redirected or provides some reference to the corresponding decision,
for triage.


HTH,

Alex.