httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From traw...@apache.org
Subject cvs commit: httpd-2.0 STATUS
Date Sat, 12 Jul 2003 13:26:43 GMT
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 <David.Deaves@dd.id.au>, 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:
   
  
  
  

Mime
View raw message