RE: [squid-users] logging of headers after request modification

Hi Alex!

Is there any other configuration option (in squid 3.2) to log if an ACL matches in the access-log? (which is all I essentially need) (besides logging to 2 different logfiles - been there and there was this issue with multiple instances of the logger daemon writing to the same file)

Everything else is a development/testing effort that is not possible in our timeframe to deploying...

Thanks,
        Martin

-----Original Message-----
From: Alex Rousskov [mailto:rousskov_at_measurement-factory.com]
Sent: Dienstag, 07. Mai 2013 17:37
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] logging of headers after request modification

On 05/07/2013 08:03 AM, Martin Sperl wrote:

> I have configured squid 3.2.7 logging with the following pattern to log:
>
> logformat xml ...<Via>%{Via}>ha</Via>...
> access_log daemon:/var/logs/squid/access_log.xml xml all
>
> But I have the problem, that the <VIA> fields stay "empty" (actually "-")...
>
> So I wonder why and how I can change that, so that I get the Via header as well...

> P.s: I am modifying the VIA header in my config like this under some circumstances:
> request_header_access Via allow CUSTOM_ACL
> request_header_access Via deny all
> request_header_replace Via mypersonalvalue

> The application sees the "expected" value in the Via header, so that
> itself is not an issue - only logging the header is NOT working as
> expected... (it actually only works IF

[http::]>ha logs request headers received by Squid and adapted by
ICAP/eCAP. It does not log request headers sent by Squid. There is
currently no logformat code to log the latter.

If you want to log outgoing Via, your options include:

1) add a logformat code to log outgoing request headers (requires
development);

2) use "note" directive and %note logformat code to log mypersonalvalue
when needed (requires Squid trunk?)

3) move Via manipulation to ICAP/eCAP while disabling Squid's Via
generation (requires writing or adjusting an adaptation service).

HTH,

Alex.

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Received on Tue May 07 2013 - 15:49:20 MDT