Thanks Chad, Henrik. If we queue each request and send it after receiving the response for the previous one, we should be okay. How will this work for HTTP progressive download videos that support "seek streaming" (pseudo-streaming) - The first request will result in server sending the video file (.swf file) but the client can send a HTTP request with a different offset (either using range requests or by using URLs like YouTube). When Squid sends out the second request to the server, how does it match the incoming bytestream to the actual request ? How does this get addressed for caching and non-caching scenarios when squid gets deployed as a proxy ? Thanks. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Persistent-Server-connections-pipelining-and-matching-responses-tp2540989p2547553.html Sent from the Squid - Users mailing list archive at Nabble.com.
