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