That can be fixed properly later, as it may get messy if proxy must dechunk (<--this bit is required by RFC2616) the (possibly huge) response from the origin server *and* send it back to the client with valid Content-Length: header (whether proxy or the dechunk filter derive that value). Buffers grow.
I'm not sure I'd say exactly 5 minutes, as opposed to exactly whatever timeout value we were hitting, but it sure felt like a timeout (same wait every time, each origin server connection sitting in a system buffer wait on FreeBSD). Ian's seen this on and off, but has a more rational test setup than any of us, I suspect.
Chuck
On Friday, August 3, 2001, at 12:01 PM, Bill Stoddard wrote:
We are adding a flush bucket after an eos. That's just wrong imho. If the eos is being
stripped out somewhere along the way (except by core), then we need to find out why that
is happening. If the eos is not being promptly propagated to the core, then there is a bug
somewhere in one of the filters where we are not properly handling an eos.
Bill
Hum..... The reason the flush bucket was added (about a month and a half ago) to both the ftp and http proxies was because the EOS was not being sent along, as needed.
If this is wrong, I am willing to fix it, but please give a suggestion as to the reason why the EOS is not making it for ~5 minutes or so.
(5 minutes sound right to you, Chuck? You were the one seeing this problem....)
Victor -- Victor J. Orlikowski | The Wall is Down, But the Threat Remains! ================================================================== [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
Chuck Murcko Topsail Group http://www.topsail.org/
