Re: [PATCH] %>la for intercepted connections

From: Tsantilas Christos <chtsanti_at_users.sourceforge.net>
Date: Wed, 31 Aug 2011 19:51:25 +0300

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...

>
>
> Amos
Received on Wed Aug 31 2011 - 17:10:47 MDT

This archive was generated by hypermail 2.2.0 : Thu Sep 01 2011 - 12:00:05 MDT