Hi Amos, Thanks for your reply. As you have mentioned, Server does not send the Content-length in the response therefore Squid sends a Connection: Close to the client. Whereas in the hit case squid knows the content-length therefore we send content-length along with keep-alive in the response to client. The Client which is sending FIN is MediaFoundation Framework(embedded within windows). The video object is rendered fine in the case of a miss but in the case of hit we see a FIN and a blank screen from the client. If the same URL is accessed using DirectShow Framework(embedded within Windows), in the case of miss the video is rendered absolutely fine. In the case of hit the video is rendered fine 4 out of 10 times. Rest of the times we see a blank screen, but there isn't any FIN from the client and wee see a complete cache hit in squid. Therefore I am guessing it might be an issue in the Client side only and not Squid. Thanks, Aditya On Thursday, 6 March 2014 2:25 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: 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
