In my configuration, my ICAP server returns to Squid either an HTTP 403 or an HTTP 302 as an adapted response, before Squid consumes any of the "virgin body". Consequently, the ICAP is destroyed before Squid has a chance to consume any of the data in "ModXact::virgin::body_pipe".
In my case, this is a valid use case. The adapted response should be forwarded to the HTTP client, but it is not. Instead, squid is waiting for "ServerStateData::virginBodyDestination" (which is a reference to "ModXact::virgin::body_pipe") to be destroyed.
In Squid's code, in the function "BodyPipe::clearConsumer" I found the comment saying
// do not abort if we have not consumed so that HTTP or ICAP can retry
// benign xaction failures due to persistent connection race conditions
My understanding is that this is controlled by icap_retry? Is the condition described above considered by Squid as a failure, or is this a bug in Squid (I already opened a Squid bug 3595 on this topic)?
In my squid config file I put the directive icap_retry allow all, to no avail. Or is the condition above handled by another configuration directive?
I am using squid 3.1.15.
Received on Tue Jul 31 2012 - 21:53:11 MDT
This archive was generated by hypermail 2.2.0 : Wed Aug 01 2012 - 12:00:02 MDT