[squid-users] Debugging http_access and http_reply_access

[squid-users at filter.luko.org]

Hi Squid users,

I'm seeking some guidance regarding the best way to debug the http_access
and http_reply_access configuration statements on a moderately busy Squid
3.5 cache.  In cases where a number (say, 5 or more) of http_access lines
are present, the goal is to find which configuration statement (if any) was
found to match for a given request, then write this information to a log for
further processing.  Example:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny out_working_hours
http_access allow working_hours whitelist
http_access allow network
http_access deny all

Let's assume each of those lines have an index (0, 1, 2 thru 8 in the
example above).  Is there any way to find which one matched?

Explored so far: using debug_options to look at sections 33 (Client Side
Routines), 88 (Client-side Reply Routines) and 85 (Client Side Request
Routines) return useful information, but it's hard to use it to identify
(programmatically) which log entries relate to which request on a busy
cache.  Activating debug logging on a busy cache also doesn't seem like the
right approach.

Also explored: creating a pair of logformat and access_log statements
corresponding to each http_access and http_reply_access statement, with the
same ACL conditions as their policy counterparts.  The idea being to create
a log entry for each http_access and http_reply_access statement, to which
Squid will write matching requests.  This approach only partially achieves
the goal, because although it collects matching requests, it doesn't take
into account the sequential nature of policy rule processing.  Eg, in the
example above, even though a request to manager may be denied by rule 3, it
might still have matched the conditions associated with rule 7, and thus be
written to that log, even though it never hit that policy rule.

Are there any other debug sections which would be more appropriate to the
task?  If not, is there another more suitable approach?

Luke