On Fri, 11 Mar 2005, Nick Lewycky wrote:
That's an interesting problem. So for a non-cacheable resource, n hits from the client must correspond to n hits to the server? Otherwise you could send the result to both clients, yes?
Correct.
So what the collapsed forwarding does in such case is that it waits for the reply headers of the request, then forwards all clients.
To mitigate this there was some tweaking to get out of the locked situation if the first request hangs by only allowing collapsing of request if reasonably current.
What's keeping it from being landed on the Squid trunk, perhaps with a configuration option? I've been considering rebasing my own branch off of it, I just haven't gotten around to trying it out. I was assuming it was unfinished.
At the time I was reasonably finished Squid-3 was in feature freeze, and now I have slightly forgotten what the current status of the branch is... but yes, it should go into the trunk.
You are welcome to give the patch a test drive, to verify the status and suitability for applying to the trunk. I brought the tree up to date yesterday but have not tried compiling it yet.
Regards Henrik
