[squid-users] Squid 4 pconn_lifetime questions

Alex Rousskov rousskov at measurement-factory.com
Fri May 10 22:48:09 UTC 2019


On 5/10/19 12:18 PM, johnr wrote:

> The configuration directive pconn_lifetime
> (http://www.squid-cache.org/Doc/config/pconn_lifetime/), seems to give the
> squid admin control over whether squid closes idle connections or moves them
> into the 'idle connection pool'...

Correct. I would say "now-idle" or "connections that just became idle"
instead of just "idle connections" to clarify a little.


> I am curious if in squid3, the connection
> was automatically terminated after being idle or if it was automatically
> moved to the idle connection pool.

It was moved to the idle connection pool. Rare pipelining cases aside,
if all connections are terminated just after they become idle, there
would be no connection reuse -- there would never be a connection in the
pool that can be reused.

In this context, pipelining aside, "became idle" simply means "done
processing the previous request".


> Given the default value for this config
> (to always move to the idle connection pool), I assume the default
> functionality between squid 3 and 4 is the same?

Correct.


> I ask because I am seeing a strange, not consistently reproducible scenario
> where I navigate to an origin through squid (SSL bump), and then after some
> time if I click on a link that navigates somewhere within the same domain,
> the browser hangs for a bit until eventually making the navigation. On the
> squid side, in the logs, I can see that there is an event in the access logs
> that is "NONE error:transaction-end-before-headers HTTP/0.0" before then
> seeing the browser issue a fresh CONNECT at which point everything seems to
> work. 

I believe error:transaction-end-before-headers can only happen for brand
new connections, not [idle] persistent ones. The same closure event
would not make sense to report as an error for an idle persistent
connection -- idle connection closures are normal benign
protocol-prescribed events, not errors or potentially abusive client
behavior.


HTH,

Alex.


More information about the squid-users mailing list