On 29 Dec 2004 20:39:47 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: trawick > Date: Wed Dec 29 12:39:46 2004 > New Revision: 123674 > > URL: http://svn.apache.org/viewcvs?view=rev&rev=123674 > Log: > does anyone remember this proxy issue? > > Modified: > httpd/httpd/branches/2.0.x/STATUS > > Modified: httpd/httpd/branches/2.0.x/STATUS > Url: > http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/STATUS?view=diff&rev=123674&p1=httpd/httpd/branches/2.0.x/STATUS&r1=123673&p2=httpd/httpd/branches/2.0.x/STATUS&r2=123674 > ============================================================================== > --- httpd/httpd/branches/2.0.x/STATUS (original) > +++ httpd/httpd/branches/2.0.x/STATUS Wed Dec 29 12:39:46 2004 > @@ -260,6 +260,14 @@ > +1: stoddard, striker, jim > -1: brianp (we need a more robust solution than what's in 2.1 right > now), > jerenkrantz (should be fixed, but I don't have time to do this) > + trawick: Reviewing the thread in Dec '02, I don't see any > + proposal about more robust solutions once it was made clear > + that Connection: Close can't be used. If Justin is correct in > + his assertion that many servers don't handle TE: chunked, then the > + current solution is reasonable. If Justin is incorrect in that > + assertion, then something more robust is possible, such as > + buffering up to N bytes in hopes of reading the entire body, > + before deciding to send C-L or T-E: chunked. Alternate > recollections?
Sleep helps. Consuming arbitrary amounts of memory to gather the entire request body in order to generate C-L could certainly be called non-robust ;) Any agreement to use the non-DOS-able and protocol-compliant implementation by default, and allow the C-L method to be enabled by a special setting? Even if somebody reworks the C-L method to be able to buffer on disk, that is wasted effort (and still a DOS concern) in many cases.
