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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
