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:rouss...@measurement-factory.com] Sent: Dienstag, 07. Mai 2013 17:37 To: squid-users@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