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

From: Martin Sperl <Martin.Sperl_at_amdocs.com>
Date: Tue, 7 May 2013 15:19:02 +0000

OK, I have done some more testing:

if I send A Via Header, then this header gets logged with "%{Via}>h" - but ONLY the value sent (not the modified version)

if I log instead the response header with %{Via}<h it gets logged without having received the header, but then the "modifications" of the header (as per the ps config) are not logged - only the "original" header generated by squid.

Also an observation in that area is that the Via header get set to the "modified" version in the "peer" request, but it does NOT get sent in the response sent to the client. That is probably why %{Via}<h is logging the "squid modified" version and not the version of "request-header-replace".

Any ideas how to solve this logging issue?

Thanks,
        Martin

p.s: As a workaround - I actually just need to know if the ACL matches or not and log that "true"/"false" value in some form...

-----Original Message-----
From: Martin Sperl
Sent: Dienstag, 07. Mai 2013 16:03
To: squid-users_at_squid-cache.org
Subject: [squid-users] logging of headers after request modification

Hi!

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

Thanks,
        Martin

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

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:19:12 MDT

This archive was generated by hypermail 2.2.0 : Tue May 07 2013 - 12:00:04 MDT