On 14/06/2013 10:23 p.m., Peter Olsson wrote:
On Fri, Jun 14, 2013 at 09:43:36PM +1200, Amos Jeffries wrote:
On 14/06/2013 9:27 p.m., Peter Olsson wrote:
We get a lot of these in our squid log:
x.x.x.x - - [14/Jun/2013:11:20:01 +0200] "NONE error:invalid-request HTTP/0.0"
400 4026 NONE:NONE
We tracked it to Spotify clients. We don't want to
block Spotify but we want to avoid filling the log
with these pointless lines.
Pointless? it alerted you to a bunch of non-HTTP traffic being thrown at
the proxy did it not?
Each and every one of these will be a TCP socket wasted until closure
timeout completes. If there were many of these at once you would be
calling it a DoS.
Good point. But we only allow squid traffic from our internal
network, with very few users, so in our view these lines are
just a waste of log space. (I forgot to mention that each
Spotify client can generate 4-5 of these lines every five
seconds.)
Since you ave tracked it down already could you explain exactly what is
going on there? Are the spotify clients attempting to send non-HTTP
traffic over port 80? or is that the result of excess data on the
connection being dumped?
Sorry, we have no details at all. We just went to the
worst offender and shut down each application until the
lines stopped.
Darn. Okay, if you have time for the job it may be worthwhile getting a
tcpdump of the traffic those clients are sending the proxy. Some well
placed bug reports could get this fixed for good.
We run a non-transparent Squid 3.1.20 in FreeBSD.
I will upgrade to Squid 3.2 this weekend, but I
suspect that these lines will still be logged in 3.2.
I tried this log_access, but it didn't work:
acl spotify_invalid urlpath_regex invalid-request
log_access deny spotify_invalid
log_access allow all
Anyone know how we can exclude these lines from the log?
"acl ... method NONE" should match them.
Doesn't seem to work unfortunately. I now have this in squid.conf,
and I tried with these lines last or first in squid.conf:
acl spotify_invalid method NONE
log_access deny spotify_invalid
log_access allow all
But the log lines still keep coming after squid -k reconfigure.
I will check again after the upgrade to Squid 3.2.
Ooh. If you have a upgrade in planning, 3.3 is better. Also you will
have level 11,2 debug traces of the raw HTTP protocol to debug this a
bit more.
Amos