Re: [PATCH] %>la for intercepted connections

On 09/08/2011 04:53 AM, Tsantilas Christos wrote:
> On 09/08/2011 06:38 AM, Amos Jeffries wrote:
>> On 08/09/11 02:21, Tsantilas Christos wrote:
>>>
>>> Normally an administrator needs to now the IP address the client
>>> connected to. It needs the IP address and not listening address.
>>> In the case of intercepted connections this information does not exist
>>> so why not get this info from listening IP address?
>>> Moreover it is practical to have ONE formating code for the above (eg
>>> easier to create a script for log analysis)
>>>
>>
>> Your clients scripts apparently need to record Squid receiving IP for
>> some kind of analysis.
>>
>> There is an email from a consultant in Africa waiting to be approved
>> moderation in squid-dev (I got it already via netfilter). Who needs to
>> reliably and definitively match logged details to packet flow
>> measurements.
>>
>>
>> To cater for both sets of user requirements we must have tags which can
>> log both details individually and simultaneously with no confusion as to
>> whether the data is coming from the packet or the receiving squid port.
>>
>> I would prefer only using al->cache->port->a.local for IP same as port,
>> but this would show dashes in the forward/accel traffic to a wildcard
>> listener. This case client destination was guaranteed to be the proxy
>> itself and we can safely avoid the dash by using tcpClient->local. In
>> all other cases the receiving IP is configured as listening port in
>> http_port or undefined.
>> See the scenarios below.
>
> I am wondering if it make sense to use only one "%>la" formating code
> and let the "{ARGUMENT}" specify its behaviour. For example use a
> "%>la{include_itercepted}" in logformat.
> Also we can extend the {ARGUMENT} part to allow more than one arguments ...

I like that, but I think Amos should decide here as he knows of and can
advocate for more use cases.

The documented difference between patched "la" options is currently
rather illusive. I doubt many users would be able to decide with
confidence which option they need. We could solve that by adding more
documentation to "la" descriptions in squid.conf, but it may be easier
and clearer to add a parameter instead.

We would need to decide what the default does. It could be the most
strict definition (log dashes in more cases), with argument(s)
broadening the scope of the option:

    %{with_intercepted,with_fake}la

or, perhaps, specifying the order of sources of information when direct
information is not available:

    %{http_port,destination}la

Thank you,

Alex.
P.S. IIRC, the argument should go in front of the option, not follow it.
Received on Thu Sep 08 2011 - 14:39:03 MDT