From: Jim Jagielski Date: Sat, 8 Dec 2007 16:12:50 +0000 (+0000) Subject: Propose alternate X-Git-Tag: 2.2.7~137 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=43b71b54de2841a6d8064f916d0a3f2ad7a6930e;p=thirdparty%2Fapache%2Fhttpd.git Propose alternate git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@602493 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/STATUS b/STATUS index da3c7bdac20..14c49c0234e 100644 --- a/STATUS +++ b/STATUS @@ -132,31 +132,10 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: ap_vrprintf(). PR 43310 trunk: http://svn.apache.org/viewvc?view=rev&revision=589461 + http://svn.apache.org/viewvc?view=rev&revision=602491 2.2.x: Trunk version of patch works - +1: jim, rpluem - niq: Doesn't allocating 2^n+1 bytes risk being horribly inefficient? - Would it make sense to reduce AP_IOBUFSIZE to 8191 so buf doesn't - go one over a big boundary? - jim: The issue is that we allocate an array of AP_IOBUFSIZE - but go beyond that (note we send the end to curpos+AP_IOBUFSIZE) - so it's not just reducing AP_IOBUFSIZE since then we would - hit the bug at 8191 boundary instead of the 8192 one. - The actual PR suggests simply removing the setting of '\0' - which looks good, but there are loads of places in the related - code where we use AP_IOBUFSIZE, so it seemed safer to me to - simply allocate an extra byte. Note that other sections of - code do this by setting the endpos to one less to "save" - space for the NUL, but they don't have related sections - which assume a set size; this does (AP_IOBUFSIZE). - niq: You're missing my point. That this patch fixes a bug is - perfectly clear. But it does so by allocating (AP_IOBUFSIZE+1) - bytes. My point: isn't that likely to be horribly inefficient - if AP_IOBUFSIZE == 2^n+1? THEREFORE this fix should be - accompanied by decrementing AP_IOBUFSIZE, so that the - allocation of AP_IOBUFSIZE+1 bytes becomes 2^n. - Correct me if I'm wrong about that mattering ever, on - any platform and architecture. + +1: jim * mod_proxy: Support variable interpolation in reverse proxy configuration (revised proposal dealing with wrowe's concerns).