You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2005/07/18 16:15:07 UTC
svn commit: r219496 - /httpd/httpd/branches/2.0.x/STATUS
Author: wrowe
Date: Mon Jul 18 07:14:43 2005
New Revision: 219496
URL: http://svn.apache.org/viewcvs?rev=219496&view=rev
Log:
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.
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?rev=219496&r1=219495&r2=219496&view=diff
==============================================================================
--- httpd/httpd/branches/2.0.x/STATUS (original)
+++ httpd/httpd/branches/2.0.x/STATUS Mon Jul 18 07:14:43 2005
@@ -111,7 +111,7 @@
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 @@
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 @@
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]
@@ -150,11 +156,6 @@
that cause the vulnerability, so I don't see how we can divide
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: