Re: [squid-users] Can one run cache_log thru an ACL?

> I have some important information that I would like to log. Like when
> the origin servers or other disappear or when squid timeouts trying to
> connect to a peer etc.etc.
>
> However I have a ton of information that my developers cite can't be
> removed (basically an http error) "Dec 10 16:34:33 cache01
> squid[11509]: httpReadReply: Excess data from" Based on some dynamic
> generated items.

Well, this is a critical error for the data connection.
A source server is pumping data into squid without proper HTTP header
information to say what it is.

The server is sending a Content-Length: header with the wrong length (too
short). Squid notices more data than was told about and terminates
connection to that source.

It's a design feature added to protect against several very nasty bits of
viral/trojan/worm infection out in the web and alert people to when it
happens.

If its your script/server causing those, needs fixing to only send the
length header when length is pre-known.
Otherwise you are under attack and have much bigger problems than squid.

>
> So obviously I want to log critical system information (well okay,
> what's critical to me, is not the same for others), but I would love
> to put in a rule that says something like !Excess data, so that my
> logs are worth something.

debug_options ALL,0
for critical and ALL,1 for important.
  ,9 is excess data inclusive.

>
> Any ideas, is this even a legit request for new releases?

We are working on finding a better debug classification system. If you
want it to go faster throw some mone into the issue. There are some
proposals floating around squid-dev but nothing decided well enough to
code yet.

>
> So in short, would love to be able to add an acl to my cache_log, so I
> can decide what is important and what is not.

While that might seem nice, consider that the initial lines were added by
a programmer who created the code to show 'em self what is happening when
things go wrong. Altering that trace locally prevents us being helpful
when you do encounter a serious problem.

Amos
Received on Mon Dec 10 2007 - 18:18:58 MST