[squid-users] grove.microsoft.com

[Amos Jeffries]

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