On 6/03/2014 5:32 p.m., aditya agarwal wrote: > Hi, > > I wanted a clarification if the following is an expected behavior from Squid. Our setup is as follows: > > Client --------> Squid -----------> Server > (Squid 2.7) (Windows Media Player) > > Miss case: > 1. Client issues a HTTP 1.0 request with Connection: keep-alive in request header > 2. Squid sends a HTTP 1.1 request to Server with Connection: Keep-Alive in request header > 3. Server responds with HTTP 1.0 with no Connection in response header > 4. Squid responds to the client with HTTP 1.1 with Connection: Close in response header > > HIT case: > 1. Client issues a HTTP 1.0 request with Connection: keep-alive in request header > 2. Squid responds with a HTTP 1.1 with Connection: Keep-Alive in response header > > Our problem is that in the HIT case the client is sending a FIN to Squid while we are serving the video!! > > So we are trying to figure out is this an expected behavior from Squid and could this behavior be our issue? Yes, for several reasons... 1) The client, Squid or server are all free to abandon the connection at any time for any reason. So while its not exactly desirable to get a FIN mid-transaction it is one of the behaviour cases that is "expected". 2) If Squid does not know the length of the reply being delivered up-front or cannot send it using chunked encoding. Then Squid is required to send Connection:close and a FIN to signal completion. 2b) HTTP/1.1 chunked encoding is forbidden when sending to a HTTP/1.0 remote end (ie your client). >From that behaviour I assume the video is delivered from the server without a Content-Length header. So when forwarding the MISS Squid is forced to use connection closure to signal completion. However with HIT, Squid should know the size and be able to send that. Resulting in keep-alive being possible. Why the FIN is coming from the client is not clear. Amos
