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

[Alex Rousskov]

On 12/31/20 7:14 AM, Moti Berger wrote:
> Indeed adding a Content-Length:0 solved the issue.
> This is BTW the preferred way for me since the URL I'm redirecting to
> explains why the redirection occurred. 

FYI: You probably assume that the user agent will automatically follow
the redirect URL. That is usually the case, but there are exceptions. It
is best to provide some basic information (like a contact link and
transaction ID) in the response body. It also helps in triage.

Glad you found a solution.

Alex.


> On Wed, Dec 30, 2020 at 6:48 PM Alex Rousskov wrote:
> 
>     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.
>