Return-Path: Delivered-To: apmail-httpd-cvs-archive@httpd.apache.org Received: (qmail 24453 invoked by uid 500); 12 Jul 2003 13:26:43 -0000 Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list cvs@httpd.apache.org Received: (qmail 24442 invoked by uid 500); 12 Jul 2003 13:26:43 -0000 Delivered-To: apmail-httpd-2.0-cvs@apache.org Date: 12 Jul 2003 13:26:43 -0000 Message-ID: <20030712132643.94580.qmail@icarus.apache.org> From: trawick@apache.org To: httpd-2.0-cvs@apache.org Subject: cvs commit: httpd-2.0 STATUS X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N trawick 2003/07/12 06:26:42 Modified: . Tag: APACHE_2_0_BRANCH STATUS Log: cvs server: [12:56:17] waiting for nd's lock in /home/cvs/httpd-2.0 Revision Changes Path No revision No revision 1.751.2.363 +12 -3 httpd-2.0/STATUS Index: STATUS =================================================================== RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.362 retrieving revision 1.751.2.363 diff -u -r1.751.2.362 -r1.751.2.363 --- STATUS 12 Jul 2003 13:01:55 -0000 1.751.2.362 +++ STATUS 12 Jul 2003 13:26:41 -0000 1.751.2.363 @@ -70,7 +70,8 @@ server/protocol.c: r1.133 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/protocol.c.diff?r1=1.132&r2=1.133 +1: rederpj, nd (though I think it's actually a bad request, being lenient - is probably the best here). + is probably the best here), trawick (prefer style changes in + r1.135 to be committed at same time) * ap_get_mime_headers(): eliminate the temporary table used to combine duplicate headers (performance enhancement) @@ -178,7 +179,7 @@ cases are always blocking. PR: 19242 Submitted by: David Deaves , William Rowe modules/ssl/ssl_engine_io.c r1.106, r1.107 (fixed minor breakage) - +1: wrowe, jerenkrantz + +1: wrowe, jerenkrantz, trawick * mod_rewrite: Let LA-U look aheads in directory context work with r->uri and not r->filename. (related to) PR 8394. (2.0 + 1.3) @@ -236,6 +237,14 @@ * ab: catch out of memory (reasoning report ID 29) support/ab.c: r1.125 +1: nd, erikabele + 0: trawick, who is not about to stand in anybody's way on this, + but has two comments nonetheless: + a) with no abort function specified for the pools, this is just + one of many possible failures + b) my guess is that a heap shortage encountered by ab is + much more likely to be caused by an ab bug instead of by a + user setup error (ulimit) or system resource shortage... + is an error message better than a coredump in that case? CURRENT RELEASE NOTES: