<div dir="ltr">I'm sorry for the bad format and for the uncompressed file.<div>Indeed adding a Content-Length:0 solved the issue.</div><div>This is BTW the preferred way for me since the URL I'm redirecting to explains</div><div>why the redirection occurred. </div><div><br></div><div>Thanks a lot for your help.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 30, 2020 at 6:48 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/30/20 10:40 AM, Moti Berger wrote:<br>
<br>
>>>> I don't see the "0 CR LF CR LF" at all, not only for those URLs that<br>
> cause the curl to hang.<br>
<br>
I suspect that none of those ICAP responses have HTTP bodies. An ICAP<br>
response without an HTTP body, in itself, is not a bug, but it probably<br>
explains the problem you are having. See below for more details.<br>
<br>
<br>
> I'm attaching a tcpdump file.<br>
<br>
FWIW, my wireshark cannot read your packet capture file: "The capture<br>
file appears to be damaged or corrupt. File has 1852785440-byte packet,<br>
bigger than maximum of 262144". In the future, you should compress such<br>
files before sharing them via email.<br>
<br>
However, looking at the ASCII parts of that capture file, I probably see<br>
the likely culprit. The ICAP response below can be considered invalid<br>
or, at least, rather difficult to handle correctly:<br>
<br>
> ICAP/1.0 200 OK<br>
> ISTag: "tmrCy72n1Qgsn1mxBipIb4jdEYdce3"<br>
> Date: Wed, 30 Dec 2020 15:07:52 GMT<br>
> Server: BaseICAP/1.0 Python/3.6.12<br>
> Encapsulated: res-hdr=0, null-body=140<br>
> <br>
> HTTP/1.1 307 Temporary Redirect<br>
> location: <a href="http://www.redirect.url" rel="noreferrer" target="_blank">http://www.redirect.url</a><br>
> Cache-Control: no-cache, no-store, must-revalidate<br>
> Pragma: no-cache<br>
<br>
<br>
The HTTP 307 response header sent by the ICAP server promises an HTTP<br>
response body (per HTTP rules), but the ICAP response has no HTTP body<br>
(per the "null-body" value in the Encapsulated header).<br>
<br>
I do not remember what Squid does in this problematic case, but I<br>
suspect the outcome is a stuck HTTP transaction.<br>
<br>
You should fix the ICAP service to either stop promising an HTTP<br>
response body or provide one. The easiest (but ugly) fix may be to add<br>
Content-Length:0 to the HTTP header returned by the ICAP service. A<br>
better fix would be to include a real body that explains why the request<br>
was redirected or provides some reference to the corresponding decision,<br>
for triage.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
</blockquote></div>