Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Stefan Eissing
Rainer,

the crashes seem the same I see when running mod-md tests: a watchdog being 
busy with openssl while the process shuts down. 

Yann wrote a patch a while back which solved it for me. But we were reluctant 
to make that change. Maybe it‘s time to revisit that. 


> Am 30.03.2020 um 01:22 schrieb Rainer Jung :
> 
> Am 26.03.2020 um 15:50 schrieb Daniel Ruggeri:
>> Hi, all;
>>Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.43:
>> [X] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>> The computed digests of the tarball up for vote are:
>> sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
>> sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
>> *httpd-2.4.43.tar.gz
>> sha512:
>> d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
>> *httpd-2.4.43.tar.gz
>> The SVN tag is '2.4.43' at r1875715.
> 
> +1 to release and thanks a bunch for RM!
> 
> Summary: all OK except for
> 
> - very few shutdown crashes on Solaris (already observed in 2.4.37, but then 
> with MPM event when statically linked, now once with prefork and shared 
> linking). Happens in mod_watchdog. Maybe prefork doesn't expect another 
> thread running and doing deinit. gdb info at end.
> 
> - another shutdown crash on Solaris in mod_watchdog for prefork. gdb info at 
> end.
> 
> - sporadic hangs with prefork plus mod_ext_filter on Linux (see separate 
> thread).
> 
> Detailed report:
> 
> - Sigs and hashes OK
> - contents of tarballs identical
> - contents of tag and tarballs identical
>  except for expected deltas
> 
> Built on
> 
> - Solaris 10 Sparc as 32 Bit Binaries
> - SLES 11+12+15 (64 Bits)
> - RHEL 6+7 (64 Bits)
> 
> For all platforms built
> 
> - with default (shared) and static modules
> - with module set reallyall
> - using --enable-load-all-modules
> - against external APR/APU 1.7.0/1.6.1
>  plus APR/APU 1.6.5/1.6.1
>  plus APR/APU 1.7.x HEAD/1.7.x HEAD with expat
>  plus APR/APU 1.7.x HEAD/1.7.x HEAD with libxml2
>  plus APR/APU from deps tarball
> 
> - using external libraries
>  - expat 2.2.9
>  - pcre 8.44
>  - lua 5.3.5 (compiled with LUA_COMPAT_MODULE)
>  - libxml2 2.9.10
>  - libnghttp2 1.40.0
>  - brotli 1.0.7
>  - curl 7.69.1
>  - jansson 2.12
> and
>  - openssl 0.9.8zh, 1.0.2, 1.0.2u, 1.0.1e, 1.0.1l, 1.1.1, 1.1.1e plus patches 
> (head of a few days ago)
> 
> - Tool chain:
>- platform gcc except on Solaris
>  (gcc 9.3.0 Solaris 10)
>- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
>  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
>-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
>and -D_XPG6
> 
> All of the 660 builds succeeded, a few are still ongoing.
> 
> - compiler warnings: only on Solaris (GCC 9.3.0):
> srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 
> 'mutex_proc_pthread_cond_methods' defined but not used 
> [-Wunused-const-variable=]
> 
> Tested for
> 
> - Solaris 10, SLES 11+12+15, RHEL 6+7
> - MPMs prefork, worker, event
> - default and static module builds
> - log level trace8
> - module set reallyall (127 modules)
> - Perl client bundle build against OpenSSL 1.1.1, 1.1.0i, 1.0.2p and 0.9.8zh
> - OpenSSL once linked statically and once as a shared library
> 
> Every OpenSSL version in the client tested with 1.1.1e plus patches in the 
> server. Tests for more server OpenSSL versions are ongoing.
> 
> The total number of test suite runs was 680 (many more to come ...).
> 
> The following test failures were seen:
> 
> a Crashes only on Solaris, only with prefork MPM and
>  dynamically linked builds.
>  The crash seems to happen only at the end of a process during pchild
>  clean up and it might be problematic, that the watchdog thread at that
>  time still exists.
>  gdb info see at end.
> 
> b Tests 4, 8 and 12 of t/modules/buffer.t
>  Not a regression
>  Tests 4, 8 and sometimes 12, always line 37
>  Relatively frequent (93 times) failures on platforms Solaris 10
>  and old SLES11 (114 times), RHEL 6 (88 times), but not on more modern
>  (and here faster) SLES 12 and RHEL 7.
>  Happens for all OpenSSL client and server
>  versions and all link types.
> 
> c Test 5 in t/modules/dav.t line 69:
>  Not a regression.
>  22 times: twice RHEL 6, 3 times RHEL 7 and 5 times SLES 11,
>  8 times SLES 12, twice SLES 15, twice Solaris 10.
>  Creation, modified and now times not in the correct order.
>  This seems to be a system issue, all tests done on NFS,
>  many tested on virtualized guests.
> 
> d Tests 45, 48, 51, 54 in t/modules/cgi.t line 232:
>  Not a regression
>  125 times once Solaris
>  Test checks log contents. Could be false positive due to
>  logs written to NFS.
> 
> Regards,
> 
> Rainer
> 
> GDB info (spor

Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Rainer Jung

Am 26.03.2020 um 15:50 schrieb Daniel Ruggeri:

Hi, all;
    Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.43:
[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
*httpd-2.4.43.tar.gz
sha512:
d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
*httpd-2.4.43.tar.gz

The SVN tag is '2.4.43' at r1875715.


+1 to release and thanks a bunch for RM!

Summary: all OK except for

- very few shutdown crashes on Solaris (already observed in 2.4.37, but 
then with MPM event when statically linked, now once with prefork and 
shared linking). Happens in mod_watchdog. Maybe prefork doesn't expect 
another thread running and doing deinit. gdb info at end.


- another shutdown crash on Solaris in mod_watchdog for prefork. gdb 
info at end.


- sporadic hangs with prefork plus mod_ext_filter on Linux (see separate 
thread).


Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12+15 (64 Bits)
- RHEL 6+7 (64 Bits)

For all platforms built

- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against external APR/APU 1.7.0/1.6.1
  plus APR/APU 1.6.5/1.6.1
  plus APR/APU 1.7.x HEAD/1.7.x HEAD with expat
  plus APR/APU 1.7.x HEAD/1.7.x HEAD with libxml2
  plus APR/APU from deps tarball

- using external libraries
  - expat 2.2.9
  - pcre 8.44
  - lua 5.3.5 (compiled with LUA_COMPAT_MODULE)
  - libxml2 2.9.10
  - libnghttp2 1.40.0
  - brotli 1.0.7
  - curl 7.69.1
  - jansson 2.12
and
  - openssl 0.9.8zh, 1.0.2, 1.0.2u, 1.0.1e, 1.0.1l, 1.1.1, 1.1.1e plus 
patches (head of a few days ago)


- Tool chain:
- platform gcc except on Solaris
  (gcc 9.3.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All of the 660 builds succeeded, a few are still ongoing.

- compiler warnings: only on Solaris (GCC 9.3.0):
srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 
'mutex_proc_pthread_cond_methods' defined but not used 
[-Wunused-const-variable=]


Tested for

- Solaris 10, SLES 11+12+15, RHEL 6+7
- MPMs prefork, worker, event
- default and static module builds
- log level trace8
- module set reallyall (127 modules)
- Perl client bundle build against OpenSSL 1.1.1, 1.1.0i, 1.0.2p and 0.9.8zh
- OpenSSL once linked statically and once as a shared library

Every OpenSSL version in the client tested with 1.1.1e plus patches in 
the server. Tests for more server OpenSSL versions are ongoing.


The total number of test suite runs was 680 (many more to come ...).

The following test failures were seen:

a Crashes only on Solaris, only with prefork MPM and
  dynamically linked builds.
  The crash seems to happen only at the end of a process during pchild
  clean up and it might be problematic, that the watchdog thread at that
  time still exists.
  gdb info see at end.

b Tests 4, 8 and 12 of t/modules/buffer.t
  Not a regression
  Tests 4, 8 and sometimes 12, always line 37
  Relatively frequent (93 times) failures on platforms Solaris 10
  and old SLES11 (114 times), RHEL 6 (88 times), but not on more modern
  (and here faster) SLES 12 and RHEL 7.
  Happens for all OpenSSL client and server
  versions and all link types.

c Test 5 in t/modules/dav.t line 69:
  Not a regression.
  22 times: twice RHEL 6, 3 times RHEL 7 and 5 times SLES 11,
  8 times SLES 12, twice SLES 15, twice Solaris 10.
  Creation, modified and now times not in the correct order.
  This seems to be a system issue, all tests done on NFS,
  many tested on virtualized guests.

d Tests 45, 48, 51, 54 in t/modules/cgi.t line 232:
  Not a regression
  125 times once Solaris
  Test checks log contents. Could be false positive due to
  logs written to NFS.

Regards,

Rainer

GDB info (sporadic) Solaris shutdown crashes during OpenSSL shutdown in 
mod_watchdog:


 fedd7668 realfree (1c0268, 61, 60, 1bfc58, 0, 1c02d8) + 154
 fedd7d9c _free_unlocked (feeb92b0, 0, d86dc, feeb9330, feeb03d8, 
1c99f8) + b0
 fedd7cd8 free (1c99f8, fe9a3ad0, d871c, fe8e4ee0, feeb03d8, 
feeb3a20) + 24
 fe8e2390 OPENSSL_LH_free (1bce10, fe9a3ad0, feeb5900, 2, fe9a3ad0, 
1cd450) + 64
 fe8bcf44 err_cleanup (0, f8800, feeb5900, fe9ed05c, fe8db4f0, 
fe9ecf4c) + 94
 fe8dee54 OPENSSL_cleanup (1, fe9ed284, fe9d3598, fe9a3240, fe9ed25c, 
fe9ed280) + 1e4

 fedc2374 _e

Re: Solaris, prefork, accept mutex and mod_ext_filter (Was: Prefork MPM and mod_watchdog)

2020-03-29 Thread Rainer Jung
I can now see the same problem on Linux (eg. RHEL 7, SLES 12 and SLES 
15) when doing testing for 2.4.43. I think it is not a regression and 
for me it is not a showstopper, but something that would be nice to fix. 
Symptom is


[Sat Mar 28 15:53:21.121461 2020] [mpm_prefork:debug] [pid 4574] 
prefork.c(919): AH00165: Accept mutex: pthread (default: pthread)
[Sat Mar 28 15:58:19.251858 2020] [mpm_prefork:emerg] [pid 6509] 
(22)Invalid argument: AH00144: couldn't grab the accept mutex
[Sat Mar 28 15:58:20.624995 2020] [mpm_prefork:emerg] [pid 4902] 
(22)Invalid argument: AH00146: couldn't release the accept mutex
[Sat Mar 28 15:58:21.410552 2020] [:emerg] [pid 4574] AH02818: MPM run 
failed, exiting


happening during t/modules/ext_filter.t and as a result all httpd 
processes are gone.


Although it happens only rarely, I think it does not happen when using 
APR 1.6, but only for 1.7 (1.7.0 and also for latest head). The accept 
mutex is pthread based. There are changes in APR 1.7 for those.


Since I only observe it for mod_ext_filter, there should be some 
dependency with the forked perl process.


I didn't yet have the opportunity to check, how much of the follwing 
description for Solaris also holds for Linux.


Regards,

Rainer

Am 03.02.2019 um 13:30 schrieb Rainer Jung:
I can now frequently reproduce running t/modules/ext_filter.t only. I 
stripped the reproducer down to the part of t/modules/ext_filter.t where 
it runs


POST "/apache/extfilter/out-limit/modules/cgi/perl_echo.pl", content => 
"foo and bar\n"


10 times in a row. If I increase the iteration count slightly to 20, the 
problem happens nearly every time. I also replaced perl_echo.pl and 
eval-cmd.pl by small C programs doing the echo and the s/foo/bar/ and 
can still reproduce.


This test involved mod_ext_filter and LimitRequestBody.

It seems I can not reproduce, if I shorten the POST body, so that it no 
longer hits the LimitRequestBody 6 configured for 
/apache/extfilter/out-limit/.


What happens, but I do not understand is:

- the first few requests are handled by two children in an alternating 
way. I can see the accept mutex being passed between these two children 
using lwp_mutex_timedlock(ADDRESS, 0x) and 
lwp_mutex_unlock(ADDRESS) using truss (Solaris variant of strace). So 
Solaris seems to implement the pthread mutexes via these lwp mutexes.


- after a few requests alternating between the two children, something 
strange happens:


   - child A returns from port_getn() for 22 (probably part of the 
accept() impl)

   - child A calls accept()
   - child A unlocks the accept mutex using lwp_mutex_unlock()
   - child B locks the accept mutex using lwp_mutex_timedlock()
   - child B calls port_associate for 22 (probably part of accept() impl)
   - child A handles the request
! - child A also calls port_associate for 22 (no sign of lock acquire)
! - child A returns from port_getn() for 22
   - child A calls accept() and starts to handle the connection
! - child B also returns from port_getn() for 22
! - child B gets EAGAIN for the accept()
   - child B calls port_associate for 22
   - child A handles the request
! - child A gets EDEADLK for pthread_mutex_lock() (this is from the 
error_log; there's no system call for this instance of 
pthread_mutex_lock() in the truss output). EDEADLK for 
pthread_mutex_lock() means that this process already has that lock.

   - child B returns from port_getn() for 22
   - child B calls accept() and starts to handle the connection
   - child A exits (now B is the only child left)
   - child B proceeds request handling
   - child B does all further port_associate(), port_getn(), and 
accept() plus connection and request handling. No more 
lwp_mutex_timedlock() or lwp_mutex_unlock() for B, maybe due to some 
optimization when only one process for a lock is left.



It is quite possible, that there is an underlying lwp_mutex or portfs 
bug here. But it is strange, that this only comes up when used with 
mod_ext_filter in combination with LimitRequestBody.


There was the fix

https://bz.apache.org/bugzilla/show_bug.cgi?id=60375

but I don't see, how this would influence the above list.

I can try to further narrow down (using static content to eliminate one 
forked child; using LimitRequestBody without mod_exit-filter etc.), but 
maybe someone already has an idea?


Regards,

Rainer


Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Eric Covener
> Well gmake test and gmake check don't seem to do anything.
>
> Has the whole test suite moved to a perl thing ?

Not moved but:  yes, the test suite is
https://svn.apache.org/repos/asf/httpd/test/framework/trunk


Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Dennis Clarke

On 2020-03-28 16:24, Gregg Smith wrote:

On 3/26/2020 7:50 AM, Daniel Ruggeri wrote:

Hi, all;
    Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.43:
[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.


+1 Windows building with the .mak files.
Thanks Daniel for RMing


Well gmake test and gmake check don't seem to do anything.

Has the whole test suite moved to a perl thing ?

Dennis


Re: svn commit: r1875853 - /httpd/httpd/trunk/docs/manual/mod/mod_md.xml

2020-03-29 Thread Marion & Christophe JAILLET

Ouch.

Sorry about that.

I was pretty sure that doc was re-built on my system, before submitting.
Don't know I did wrong.

CJ

Le 29/03/2020 à 15:09, cove...@apache.org a écrit :

Author: covener
Date: Sun Mar 29 13:09:41 2020
New Revision: 1875853

URL: http://svn.apache.org/viewvc?rev=1875853&view=rev
Log:
duplicated

[skip ci]

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_md.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_md.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_md.xml?rev=1875853&r1=1875852&r2=1875853&view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_md.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_md.xml Sun Mar 29 13:09:41 2020
@@ -1240,7 +1240,6 @@ MDMessageCmd /etc/apache/md-message
  
  MDActivationDelay duration
  
-
  server config
  
  Available in version 2.4.42 and later




Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Daniel Ruggeri
On 3/27/2020 12:58 PM, William A Rowe Jr wrote:
> On Fri, Mar 27, 2020 at 12:34 PM Steffen  > wrote:
>
> +1 All fine on Windows.
>
>
> Your's are still the .dsp based builds, right? I can confirm also on
> the CMake flavor.

Thanks, Bill. Shall this response be considered a +1 for the purposes of
the release vote?

-- 
Daniel Ruggeri



Re: [VOTE] Release httpd-2.4.43

2020-03-29 Thread Daniel Ruggeri
On 3/26/2020 9:50 AM, Daniel Ruggeri wrote:
> Hi, all;
>    Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.43:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
> sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
> *httpd-2.4.43.tar.gz
> sha512:
> d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
> *httpd-2.4.43.tar.gz
>
> The SVN tag is '2.4.43' at r1875715.


For my own vote:

[X] +1: It's not just good, it's good enough!

system:
  kernel:
    name: Linux
    release: 4.9.0-8-amd64
    version: #1 SMP Debian 4.9.144-3.1 (2019-02-19)
    machine: x86_64

  libraries:
    openssl: "1.1.1e"
    openldap: "2.4.49"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.40.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.4"
    lua: "5.3.5"
    curl: "7.69.1"

-- 
Daniel Ruggeri



Bug report for Apache httpd-2 [2020/03/29]

2020-03-29 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid |
|27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins|
|28657|Ver|Nor|2004-04-28|mod_negotiation should not store Content-Location |
|29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp|
|29510|Ass|Enh|2004-06-10|ab does not support multiple cookies  |
|29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client |
|30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do|
|30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ|
|31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in |
|31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use|
|31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules|
|32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern|
|32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak|
|33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)|
|33207|Opn|Nor|2005-01-23|Results of my suexec.c code audit |
|34270|Inf|Nor|2005-04-01|Large POSTs over SSL from Internet Explorer do not|
|34519|New|Enh|2005-04-19|Directory index should emit valid XHTML   |
|35098|Ver|Maj|2005-05-27|Install fails using --prefix  |
|35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c|
|35768|Ver|Nor|2005-07-17|Missing file logs at far too high of log level|
|36636|Opn|Maj|2005-09-13|database write lock taken for PROPFIND operations |
|36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for|
|36710|Opn|Blk|2005-09-19|CGI output not captured   |
|37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo|
|37355|Opn|Enh|2005-11-04|Allow to specify Proxy-Authorization in ProxyRemot|
|37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i|
|38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r|
|38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes|
|38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve|
|39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning |
|39287|