Thanks for the response. I should have clarified further. See inline below/ > If we queue each request and send it after receiving the response for the > previous one, we should be okay. [Henrik]How would that make you do okay? ---> I meant that there is no problem in matching request to response if they are "sequenced" to the server as one transaction after another. > 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 ? [Henrik]It matches the response to the request, just as done for any other request. No difference. -----> Isn't it impossible to match the response to the request - First request to the server is to start sending the video file - Let's say this maps to TCP fragment 1 through 1000 (assuming that the video file is 536000 bytes) - Before the entire video is sent, client sends a request (HTTP range request or separate URL with the offset embedded) to start sending from the middle of the video (client does a "fast forward"). Squid has to send this to the server before receiving the complete response to the original HTTP request. If the server hasn't sent *all* of the original video, it'll transmit starting from the location specified in the request. Squid could now receive TCP fragments from the original stream followed by TCP fragments from the "mid-video" section. There is no way to identify (and cache) the "mid-video" section separately. This makes it hard to cache segments sent in response to range requests. This is the issue I was discussing. Regards Henrik Free Embedda -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Persistent-Server-connections-pipelining-and-matching-responses-tp2540989p2547693.html Sent from the Squid - Users mailing list archive at Nabble.com.
