Still looking for a vote on this fix to core for 1.3, preventing modules from seeing an invalid C-L + T-E combination from the client per RFC 2616. This does not apply to proxy (as implemented now) but may affect other handlers as I noted below. The sanest action seems to be; adopt our 2.0 core change.
The clean patch to backport to 1.3 is at http://people.apache.org/~wrowe/httpd-1.3-proto-cl-te.patch With respect to fixes in individual modules, one should still remember that this isn't a panacea, it's still possible for any other invalid module to reinsert a content-length input header at your handler before it's invoked. But it seems worthwhile to go ahead and fix the 80/20 with these 3 lines of code already committed to trunk and 2.0.x. Bill At 04:36 PM 7/19/2005, William A. Rowe, Jr. wrote: >At 04:11 PM 7/19/2005, Joe Orton wrote: >>On Tue, Jul 19, 2005 at 02:59:14PM -0500, William Rowe wrote: >>> Paul? Joe? Jeff? Someone? >>> >>> This is the only showstopper to a 1.3.34 candidate today, >>> since 1.3.x/src/modules/proxy/mod_proxy.c rejects T-E >>> for proxy request bodies. >> >>Since the 1.3 proxy already rejects such requests what does this patch >>actually fix? > >Hmmm... > > mod_isapi? > mod_php? > mod_cgi? > mod_jk? > >shall I keep digging?
