On 01/09/11 04:51, Tsantilas Christos wrote:
On 08/28/2011 10:10 PM, Amos Jeffries wrote:
On 29/08/11 06:39, Tsantilas Christos wrote:
On 08/27/2011 08:03 PM, Amos Jeffries wrote:
On 28/08/11 02:50, Tsantilas Christos wrote:
%>la for intercepted connections
This patch adjusts the %>la logformat code handling for intercepted
connections
based on the following rules:
- If the corresponding http_port or https_port option has an explicit
listening host name or IP address, then log the IP address.
- Otherwise, log a dash character.
Also adjusts %>lp logformat code handling for intercepted
connections to
always
log the port number from the corresponding http_port or https_port
option.
+1. Looks fine.
Amos
I will commit this patch to trunk if there is not any objection.
PS. I forgot to mention that this is a Measurement Factory project.
This whole thing itches a worry in the back of my mind. Updating the
release notes about %>la creation today makes me realize what it is.
We are using ">" on tags to indicate incoming things, usually state
shared with the clients view of the world. This change makes the tag
loose that overlap with the clients world view on intercepted traffic.
What do you think about resurrecting %la / %lp for this data instead?
I think we should not be so strict with the definitions, but instead we
should trying to see what is better and useful to system administrators
and squid users.
Normally the %>la/%>lp formating code is useful to examine where the
client connected to, in the case of multiple http_port definitions.
I can not see any gain for using two different %*la codes (%>la and %la).
In the other hand if the "%la/%lp" formating codes has all the
functionality implemented in this patch for the %>la and %>lp (display
info FOR BOTH intercepted and normal connections) I have not any problem...
That is what I mean.
%>la to always display tcpClient->local with a config documentation
note about it being external IPs in intercepted traffic.
%la to display cache.caddr with a config documentation note that it is
the squid receiving *_port details as known by Squid (caddr also used by
icp_port and htcp_port on their messages).
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.15
Beta testers wanted for 3.2.0.10
