From 0b2138eb02909b41d3e56773685142354a6ffa42 Mon Sep 17 00:00:00 2001 From: "William A. Rowe Jr" Date: Thu, 14 Jul 2005 21:22:49 +0000 Subject: [PATCH] Note two patches available for 2.0.55 There is low hanging fruit here, if anyone's up to committing a few backports in the next day before a release candidate is tagged ;-) git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@219103 13f79535-47bb-0310-9956-ffa450edef68 --- STATUS | 47 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/STATUS b/STATUS index f3f075b27f7..9d72263bfd7 100644 --- a/STATUS +++ b/STATUS @@ -111,6 +111,41 @@ RELEASE SHOWSTOPPERS: * Various fixes to T-E and C-L processing from trunk + Refactor mod_proxy_http.c's Transfer-Encoding/Content-Length elections + since they didn't follow RFC 2616, in fact didn't seem to make much + sense at all. Patch to migrate request-body-handling from trunk/... + http://people.apache.org/~wrowe/httpd-2.0-proxy-request.patch + Revert r219061 to properly test this patch. + + +1 wrowe, jimjag + + trawick noted on list: we elected C-L not for efficiency, but because + it's the most widely supported [paraphrasing] + wrowe notes: I agree - this new patch always chooses C-L for any + 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. + 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. + trawick We are counting bytes in stream_reqbody_cl but filters can + change the size? [p] + wrowe Yes - which is why the patch prefers spool_reqbody_cl unless + 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. + 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. + trawick Please split philosophy from rfc violations from security + fixes in the CHANGES log? [p] + wrowe Well, I'll split that default HTTP/1.0 -> HTTP/1.0 requests + behavior and envvar. The others are all a bit to intertwined, + the Watchfire report spelled out that it's different behavior + and RFC 2616 deviations that cause the vulnerability, so I + don't see how we can divide the issues. + PATCHES ACCEPTED TO BACKPORT FROM TRUNK: @@ -161,8 +196,8 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: the changes in the httpd-2.0.x to be done in order for NetWare to work as expected when calling apr_proc_create. Should I do both, APR and Http, at the same time? - wrowe: commit to APR. Use an APR version test to determine if the - old or new behavior should be used in httpd. In future versions + wrowe: commit to APR. Use an APR version test *in httpd* to determine + if the old or new behavior should be used in httpd. In future versions you could remove the test altogether. *) mod_actions: Regression from 1.3: the file referred to must exist. @@ -203,6 +238,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! ] + *) Correct RFC 2616 non-compliance by refusing to proxy a request body + in a TRACE request, unless TraceEnable extended is configured. + Introduces TraceEnable [on|off|extended] to give the administrator + full control of TRACE request handling. RFC 2616 does NOT require + TRACE (although to disable remains silly). Current patch at; + http://people.apache.org/~wrowe/httpd-2.0-trace.patch + +1 wrowe, jimjag + *) mod_headers: Support {...}s tag for SSL variable lookup. http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff +1: jorton, trawick -- 2.47.2