[squid-users] ICAP Persistent Connections vs Retries (with code review)

[Alex Rousskov]

On 05/11/2017 07:30 PM, Amos Jeffries wrote:

> Requests which are not retriable are not able to be re-sent [...] 
> As such those requests need a new TCP connection to be opened to
> guarantee the absence of immediate closure. When they complete with
> their transaction it gets added to the pool for other traffic to use if
> they can.

The above is accurate, including the snipped parts documenting the
rationale. BTW, since HTTP and ICAP share the same basic connection
persistency model, you may find more information reading about these
general problems in HTTP-related documents.


> As far as I know RESPMOD transactions should all be retriable unless the
> body payload length is unknown at the HTTP level (lack of Content-Length
> header).

This is inaccurate. A REQMOD or RESPMOD transaction is deemed retriable
at the time when a connection is chosen/open if:

* Squid can send a preview or
* Squid can buffer the entire HTTP message body.

The "known length" aspect affects the second bullet, but that bullet
covers more cases than just messages with Content-Length. And there may
be more conditions in the code than the bullets cover -- I have not checked.


> They can also become non-retriable when the response from the ICAP
> server has been received by Squid and already started delivery to the
> HTTP client.

This is accurate (including the snipped part about the irrelevance to
the connection choice).


HTH,

Alex.