On 10/31/18 11:20 AM, Arunabha Saha wrote:
>>As with any timeout, it is impossible to say in general which side of
>>the connection is at fault. This case has at least three sides: It could
>>be the HTTP agent, Squid, and/or the ICAP service. Did one of them stall
>>the transaction? Or was the
>As with any timeout, it is impossible to say in general which side of
>the connection is at fault. This case has at least three sides: It could
>be the HTTP agent, Squid, and/or the ICAP service. Did one of them stall
>the transaction? Or was the ICAP service just too impatient? See option
>#4
On 10/30/18 6:45 PM, Arunabha Saha wrote:
> Squid 3.5.25 does not seem to recognise the 408 request timeout error
> code from ICAP.
Squid effectively recognizes ICAP 408 response as an ICAP transaction
error response and blames the ICAP service for that error. That
(minimal) support can be
Squid 3.5.25 does not seem to recognise the 408 request timeout error code
from ICAP.
The more troublesome issue for me is the exception it generates and then
declares ICAP down after a certain number of such exceptions.
I don't want to disable the failure limit entirely given that we can often