On 16/04/2016 11:13 a.m., Michael Pelletier wrote: > Hello, > Bellow is the message that I retrieve from logstash. We use logstash as our > logging system. Now, I do add tags to log messages in log stash. I believe > the %st is my size right? Yes that should be teh sum of request and reply payload sizes. > > Apr 14 01:31:13 Proxy-SI-1 (squid-2): Proxy-SI-1 1460611873.853 0 2 > 10.88.14.225 TCP_DENIED_ABORTED 301 2147480505 535 2147479970 POST 1.0 > text/html - - - - 3128 - [Mozilla/4.0 (compatible; MSIE 5.5; Win32)] [-] > sq_err:[301 Access Denied] c_hdr:[Accept: */*\r\nContent-Type: > application/octet-stream\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 5.5; > Win32)\r\nUserAgent: blugro3relay.groove.microsoft.com\r\nContent-Length: > 2147479552\r\nPragma: no-cache\r\nCache-Control: no-cache\r\nExpires: > 0\r\nCache-Control: max-age=0\r\n] s_hdr:[HTTP/1.1 301 Moved > Permanently\r\nServer: squid/3.4.13\r\nMime-Version: 1.0\r\nDate: Thu, 14 > Apr 2016 05:31:13 GMT\r\nContent-Type: text/html\r\nContent-Length: > 0\r\nLocation: > http://blockmessage.palmbeach.k12.fl.us/block_message.php?clientaddr=10.88.14.225&clientname=-&clientuser=-&clientgroup=SDPBC-Network&targetgroup=Blacklist&url=HTTP://blugro3relay.groove.microsoft.com\r\nX-Squid-Error: > 301 Access Denied\r\n\r] > The client is an HTTP/1.0 agent - that is part of the problem here. In HTTP/1.0 the only way to stop the POST payload being sent is to tear down the entire TCP connection. Which is what Squid should do naturally after those 2GB have finished arriving. However Squid is being told how big it is up front. So the decision to do so is possible. Provided that you have also not configured the quick_abort settings to be "infinity" / keep-going then it may be reasonable to abort the POST arrival. There appear to be two bugs involved: 1) Squid not sending a Connection header in its response. Which tells the 1.0 client what Squid expects to happen. This is a bug. To a 1.0 client Squid should always be sending either keep-alive or close explicitly. It is reasonable to expect 'Connection:close' here (relative to quick_abort) given that payload has a pre-known 2GB size and the response was internally generated by Squid. * You could try a newer Squid than 3.4, we might have fixed it already. If the current releases still do the same please report it to our bugzilla (against Squid 3.4 version) so this wont get lost. 2) The connection not being closed when the client received the respone. This one is tricky. Squid has *no* knowledges of when that response is/was/will be received b the other end. There are some popular tools out there which would send the entire 2GB of data before even trying to read any bytes of Squid response. So if Squid closes the connection itself earlier than that, the whole 301 could be lost and all the client sees is a broken proxy. So we have to send the "Connection:close" and wait for the client to obey. Fixing bug #1 above might solve the issue if the client is behaving properly. Otherwise it will have to be fixed at the client end. Even if Squid tears down the TCP connection that closure signal / packet will not arrive until the client tries to read(2)/write(2) - in the case of the broken clients that could be after the 2GB was sent anyway. So no useful improvement. - and good luck getting MSIE 5.5 stuff fixed these days :-( You may have lucked out if someone has or can fix #1. I currently lack the time sorry. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
