From: William A. Rowe Jr Date: Mon, 18 Jul 2005 14:14:43 +0000 (+0000) Subject: New fixes yesterday; slightly revised patch to match. X-Git-Tag: 2.0.55~124 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=120d1bc5ca089bca58875ea97d255bf0858e3ab4;p=thirdparty%2Fapache%2Fhttpd.git New fixes yesterday; slightly revised patch to match. The -3.patch now covers every one of my test cases flawlessly, please ruthlessly test/abuse/review this final(?) patch. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@219496 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/STATUS b/STATUS index c656088f349..e60d614f86c 100644 --- a/STATUS +++ b/STATUS @@ -111,7 +111,7 @@ RELEASE SHOWSTOPPERS: sense at all. Patch to migrate request-body-handling from trunk/ based on 2.1-dev request body handling behavior (although just a bit more conservative on the side of C-L spooling)... - http://people.apache.org/~wrowe/httpd-2.0-proxy-request-2.patch + http://people.apache.org/~wrowe/httpd-2.0-proxy-request-3.patch Revert r219061 to properly test this patch, as r219061 masks the underlying bug (although it is a -good- patch in and of itself). @@ -123,14 +123,14 @@ RELEASE SHOWSTOPPERS: C-L body received. If the origin kicks out LENGTH_REQUIRED for a T-E body it's always up to the client to react. Note proxy-sendchunks can override this behavior. - - trawick noted on list: why force-proxy-http-1.0 if the client is an - HTTP/1.0 request? [p] - wrowe Because we aren't going to keep it alive if the client is an - HTTP/1.0 who's about to disconnect on us anyways. Minimize - possible confusion over expected request/response headers. - roy noted on list: that violates the RFC - wrowe this change is dropped then :) + roy Notes on list: we must always prefer C-L if it's going to fit + in our brigade. + wrowe good point; the revised patch prereads MAX_MEM_SPOOL and will + try reading that before choosing C-L or T-E. + wrowe adds; After testing, I've determined one brigade isn't enough, + so I've extended this to a loop up to MAX_MEM_SPOOL, we will + fetch up enough body to fill MAX_MEM_SPOOL and hopefully + hit the C-L code path most of the time. trawick We are counting bytes in stream_reqbody_cl but filters can change the size? [p] @@ -138,10 +138,16 @@ RELEASE SHOWSTOPPERS: the filter stack is unchanged from proto_input_filters. The protocol filters shouldn't be changing content size. And when it happens, we have to barf or we have a split request. + The old behavior was worse; we would stream the request body + in additional cases without looking to see if the byte count + matched Content-Length. Easy opportunity for split requests. trawick What specifically was done for conformance to RFC 2616? [p] wrowe Elect the appropriate body handling, and ensure that body - request contains the required *single* T-E or C-L header. + request contains the required *single* T-E or C-L header, + and there are far few code paths to stream_reqbody_cl which + was most likely to create split requests by reporting the + wrong C-L. trawick Please split philosophy from rfc violations from security fixes in the CHANGES log? [p] @@ -151,11 +157,6 @@ RELEASE SHOWSTOPPERS: the issues of correctly sending the body and choosing the transport flavor. - roy Notes on list: we must always prefer C-L if it's going to fit - in our brigade. - wrowe good point; the revised patch prereads MAX_MEM_SPOOL and will - try reading that before choosing C-L or T-E. - PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ please append new backports at the end of this list not the top. ]