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. > > 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. Thanks! Peter Olsson