Re: iOS 14 / macOS 11 and HTTP/3 support

2020-06-28 Thread William A Rowe Jr
On Sun, Jun 28, 2020 at 5:53 AM Graham Leggett  wrote:

> On 27 Jun 2020, at 14:48, Luca Toscano  wrote:
>
> > the challenges are the same one discussed in your previous email
> > thread (
> https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E
> ).
> > I think that everybody would love to start working/helping on adding
> > HTTP/3 support but the work to be done is huge, involves invasive
> > changes to the httpd's source code and the current dev resources don't
> > have (rightfully) bandwidth to support the current codebase and plan a
> > major refactoring.
>
> I would be careful with wide reaching statements like this.
>
> I’ve been working on identifying and removing blockers in various parts of
> the httpd subsystems that prevent httpd to be cleanly event driven, and
> most of those blockers have been removed.
>
> The underlying architecture of httpd is very strong, and would support new
> protocols without too much trouble.
>
> The main point is that it must be done carefully and properly, but this is
> not a reason to not do it at all.
>

I didn't read anyone saying "don't do it", in fact all the communication
has said exactly the opposite.

Irrespective of getting the code into a state where true async behavior
"just works", and request handlers will have no problem with free threading
(this is not true of PHP and other third party modules), that still leaves
a huge hole.

Right now, we couple httpd <-> mod_ssl <-> mod_http2 <-> nghttp2 <-> httpd
filters and handler. This works, since the protocol layer exists apart from
the SSL stack.

What we are running up against at another project is the tight interconnect
between the ssl protocol implementation and the quic implementation. They
are almost insperable. You can't do this with mod_ssl out-of-the-box. There
are hacks of mod_ssl to enable the callbacks and sideways ingress points
which the quic transport protocol requires, but effectively it's a marriage
between Google's quiche and boringssl, or another quic implementation and
their elected ssl transport.

So it might be that mod_ssl almost entirely disappears in this scenario,
replaced by a triplet of httpd skin around one specific quic tightly
coupled to one specific tls provider.

The openssl project has published that following 3.0.0 GA, they are
devoting energies into implementing all of the hooks into openssl required
of a quic implementation (alongside building a FIPS crypto provider coupled
to 3.0.0.) These were simply things that current 3.0.0 release plan
couldn't accommodate, and they were further worried that the specifics of
the spec weren't sufficiently ironed out during their pre-alpha development
stage to commit to 10+ years of support for mangled API's.

Tatsuhiro himself has been contributing commits to
https://github.com/ngtcp2/nghttp3 although I have yet to read any specific
roadmap or plan on what direction he is taking his efforts. At $dayjob OSS
projects, it's largely been a matter of consuming his implementation of
nghttp2, while consuming boringssl+quic to get to http3 for the time being.

I don't think Luca's general guidance is off-base, nor that his cautions
are at all misplaced, and he has perhaps taken a fair assessment of the
complexity of this challenge.


Re: Still Failing: apache/httpd#896 (trunk - 9af2218)

2020-06-28 Thread Graham Leggett
On 28 Jun 2020, at 15:47, Travis CI  wrote:

> apache / httpd
> trunk
> Build #896 is still failing9 mins and 44 secs

Travis mavens, I’ve been looking for the test/perl-framework directory as 
referred to in --with-test-suite=test/perl-framework but I’m coming up with a 
blank.

http-tests/trunk currently succeeds as follows:

[minfrin@bob httpd-test]$ t/TEST t/modules/dav.t
/tmp/httpd-trunk/bin/httpd  -d 
/home/minfrin/src/apache/sandbox/httpd/httpd-test/t -f 
/home/minfrin/src/apache/sandbox/httpd/httpd-test/t/conf/httpd.conf -D APACHE2 
-D PERL_USEITHREADS
using Apache/2.5.1-dev (event MPM)

waiting 60 seconds for server to start: .[Sun Jun 28 15:13:34.054340 2020] 
[core:warn] [pid 5058:tid 139811004360960] AH00111: Config variable ${DOCROOT} 
is not defined
[Sun Jun 28 15:13:34.058092 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3552): Setting LogLevel for all modules to trace8
[Sun Jun 28 15:13:34.059108 2020] [core:trace6] [pid 5058:tid 139811004360960] 
core.c(3570): Cannot find module 'rewrite', trying 'rewrite_module'
[Sun Jun 28 15:13:34.059122 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3581): Setting LogLevel for module mod_rewrite.c to trace8
[Sun Jun 28 15:13:34.060338 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3552): Setting LogLevel for all modules to info
[Sun Jun 28 15:13:34.060356 2020] [core:trace6] [pid 5058:tid 139811004360960] 
core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060360 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3581): Setting LogLevel for module core.c to crit
[Sun Jun 28 15:13:34.060365 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3552): Setting LogLevel for all modules to crit
[Sun Jun 28 15:13:34.060370 2020] [core:trace6] [pid 5058:tid 139811004360960] 
core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060373 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3581): Setting LogLevel for module core.c to info
[Sun Jun 28 15:13:34.060377 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3552): Setting LogLevel for all modules to crit
[Sun Jun 28 15:13:34.060394 2020] [core:trace6] [pid 5058:tid 139811004360960] 
core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060401 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3581): Setting LogLevel for module core.c to info
[Sun Jun 28 15:13:34.060408 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3552): Setting LogLevel for all modules to crit
[Sun Jun 28 15:13:34.060413 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3552): Setting LogLevel for all modules to info
[Sun Jun 28 15:13:34.060418 2020] [core:trace6] [pid 5058:tid 139811004360960] 
core.c(3570): Cannot find module 'core', trying 'core_module'
[Sun Jun 28 15:13:34.060422 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3581): Setting LogLevel for module core.c to crit
[Sun Jun 28 15:13:34.060427 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3552): Setting LogLevel for all modules to info
[Sun Jun 28 15:13:34.061870 2020] [core:trace6] [pid 5058:tid 139811004360960] 
core.c(3570): Cannot find module 'proxy_hcheck', trying 'proxy_hcheck_module'
[Sun Jun 28 15:13:34.061883 2020] [core:trace3] [pid 5058:tid 139811004360960] 
core.c(3581): Setting LogLevel for module mod_proxy_hcheck.c to trace4
[Sun Jun 28 15:13:34.063067 2020] [ssl:warn] [pid 5058:tid 139811004360960] 
AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and 
later
[Sun Jun 28 15:13:34.063079 2020] [ssl:warn] [pid 5058:tid 139811004360960] 
AH10235: SSLRandomSeed is deprecated and has no effect with OpenSSL 1.1.1 and 
later

waiting 60 seconds for server to start: ok (waited 0 secs)
server localhost:8529 started
server localhost:8530 listening (mod_nntp_like)
server localhost:8531 listening (mod_nntp_like_ssl)
server localhost:8532 listening (mod_ssl)
server localhost:8533 listening (ssl_optional_cc)
server localhost:8534 listening (ssl_pr33791)
server localhost:8535 listening (ssl_ocsp)
server localhost:8536 listening (cve_2011_3368_rewrite)
server localhost:8537 listening (proxy_http_reverse)
server localhost:8538 listening (proxy_http_nofwd)
server localhost:8539 listening (cve_2011_3368)
server localhost:8540 listening (mod_headers)
server localhost:8541 listening (error_document)
server localhost:8542 listening (http_unsafe)
server localhost:8543 listening (http_strict)
server localhost:8544 listening (remote_ip)
server localhost:8545 listening (mod_proxy)
server localhost:8546 listening (proxy_http_bal1)
server localhost:8547 listening (proxy_http_bal2)
server localhost:8548 listening (proxy_http_balancer)
server localhost:8551 listening (proxy_fcgi)
server localhost:8552 listening (mod_cache)
server localhost:8553 listening (h2c)
server localhost:8554 listening (h2)
server localhost:8555 listening (core)
server localhost:8556 

Re: svn commit: r1879306 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h

2020-06-28 Thread Graham Leggett
On 28 Jun 2020, at 15:33, Greg Stein  wrote:

> Hey Graham ... what's the goal with exposing these things? (this rev, and 
> prior) ... I don't see any emails describing "why". Generally, it would be 
> "shrug" ... but you're changing the MMN, and I don't see any discussion on 
> why/goal.

Picking up the CalDAV work again.

Since mod_dav was written there have been a host of RFCs that use the REPORT 
method, but mod_dav is written in such a way that only a versioning 
implementation is allowed to use REPORT.

This has led to some offensive workarounds (an input filter to try and undo the 
read of a report after finding the report wasn’t for that module, yuck yuck 
yuck).

Two works-in-progress:

https://github.com/minfrin/mod_dav_calendar - RFC4791 Calendaring Extensions to 
WebDAV
https://github.com/minfrin/mod_dav_access - RFC3744 WebDav Access Control 
Protocol

CalDAV mandates strong ETags as per 
https://tools.ietf.org/html/rfc4791#section-5.3.4, and Apple Calendar breaks 
decisively without it.

Regards,
Graham
—



Still Failing: apache/httpd#896 (trunk - 9af2218)

2020-06-28 Thread Travis CI
Build Update for apache/httpd
-

Build: #896
Status: Still Failing

Duration: 9 mins and 44 secs
Commit: 9af2218 (trunk)
Author: Graham Leggett
Message: Add implementation of deliver_report and gather_reports to mod_dav.c.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1879307 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/8556bcf4f44c...9af2218159e9

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/702872240?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.



Still Failing: apache/httpd#895 (trunk - 8556bcf)

2020-06-28 Thread Travis CI
Build Update for apache/httpd
-

Build: #895
Status: Still Failing

Duration: 10 mins and 47 secs
Commit: 8556bcf (trunk)
Author: Graham Leggett
Message: Add hooks deliver_report and gather_reports to mod_dav.h. Allows other
modules apart from versioning implementations to handle the REPORT method.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1879306 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/4a0c08e064e2...8556bcf4f44c

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/702870965?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.



Re: svn commit: r1879306 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h

2020-06-28 Thread Greg Stein
Hey Graham ... what's the goal with exposing these things? (this rev, and
prior) ... I don't see any emails describing "why". Generally, it would be
"shrug" ... but you're changing the MMN, and I don't see any discussion on
why/goal.

Thanks,
-g


On Sun, Jun 28, 2020 at 8:17 AM  wrote:

> Author: minfrin
> Date: Sun Jun 28 13:17:26 2020
> New Revision: 1879306
>
> URL: http://svn.apache.org/viewvc?rev=1879306=rev
> Log:
> Add hooks deliver_report and gather_reports to mod_dav.h. Allows other
> modules apart from versioning implementations to handle the REPORT method.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/modules/dav/main/mod_dav.c
> httpd/httpd/trunk/modules/dav/main/mod_dav.h
>
> Modified: httpd/httpd/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Sun Jun 28 13:17:26 2020
> @@ -1,6 +1,10 @@
>   -*- coding:
> utf-8 -*-
>  Changes with Apache 2.5.1
>
> +  *) Add hooks deliver_report and gather_reports to mod_dav.h. Allows
> other
> + modules apart from versioning implementations to handle the REPORT
> method.
> + [Graham Leggett]
> +
>*) Add dav_get_provider(), dav_open_lockdb() and dav_close_lockdb()
> mod_dav.h.
>   [Graham Leggett]
>
>
> Modified: httpd/httpd/trunk/include/ap_mmn.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/include/ap_mmn.h (original)
> +++ httpd/httpd/trunk/include/ap_mmn.h Sun Jun 28 13:17:26 2020
> @@ -643,6 +643,8 @@
>   * Add bnotes to request_rec.
>   * 20200420.8 (2.5.1-dev)  Add dav_get_provider(), dav_open_lockdb() and
>   * dav_close_lockdb() mod_dav.h.
> + * 20200420.9 (2.5.1-dev)  Add hooks deliver_report and gather_reports to
> + * mod_dav.h.
>   */
>
>  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> @@ -650,7 +652,7 @@
>  #ifndef MODULE_MAGIC_NUMBER_MAJOR
>  #define MODULE_MAGIC_NUMBER_MAJOR 20200420
>  #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 8/* 0...n */
> +#define MODULE_MAGIC_NUMBER_MINOR 9/* 0...n */
>
>  /**
>   * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
>
> Modified: httpd/httpd/trunk/modules/dav/main/mod_dav.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/mod_dav.c?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/mod_dav.c (original)
> +++ httpd/httpd/trunk/modules/dav/main/mod_dav.c Sun Jun 28 13:17:26 2020
> @@ -5005,6 +5005,8 @@ APR_HOOK_STRUCT(
>  APR_HOOK_LINK(gather_propsets)
>  APR_HOOK_LINK(find_liveprop)
>  APR_HOOK_LINK(insert_all_liveprops)
> +APR_HOOK_LINK(deliver_report)
> +APR_HOOK_LINK(gather_reports)
>  )
>
>  APR_IMPLEMENT_EXTERNAL_HOOK_VOID(dav, DAV, gather_propsets,
> @@ -5021,3 +5023,16 @@ APR_IMPLEMENT_EXTERNAL_HOOK_VOID(dav, DA
>   (request_rec *r, const dav_resource
> *resource,
>dav_prop_insert what, apr_text_header
> *phdr),
>   (r, resource, what, phdr))
> +
> +APR_IMPLEMENT_EXTERNAL_HOOK_RUN_FIRST(dav, DAV, int, deliver_report,
> +  (request_rec *r,
> +   const dav_resource *resource,
> +   const apr_xml_doc *doc,
> +   ap_filter_t *output, dav_error
> **err),
> +  (r, resource, doc, output, err),
> DECLINED)
> +
> +APR_IMPLEMENT_EXTERNAL_HOOK_VOID(dav, DAV, gather_reports,
> +   (request_rec *r, const dav_resource
> *resource,
> +apr_array_header_t *reports,
> dav_error **err),
> +   (r, resource, reports, err))
> +
>
> Modified: httpd/httpd/trunk/modules/dav/main/mod_dav.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/mod_dav.h?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/mod_dav.h (original)
> +++ httpd/httpd/trunk/modules/dav/main/mod_dav.h Sun Jun 28 13:17:26 2020
> @@ -650,10 +650,10 @@ DAV_DECLARE(void) dav_xmlns_generate(dav
>  ** mod_dav 1.0). There are too many dependencies between a dav_resource
>  ** (defined by ) and the other functionality.
>  **
> -** Live properties are not part 

Still Failing: apache/httpd#894 (trunk - 4a0c08e)

2020-06-28 Thread Travis CI
Build Update for apache/httpd
-

Build: #894
Status: Still Failing

Duration: 10 mins and 35 secs
Commit: 4a0c08e (trunk)
Author: Graham Leggett
Message: Add dav_get_provider(), dav_open_lockdb() and dav_close_lockdb() 
mod_dav.h.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1879305 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/8de97e5fabff...4a0c08e064e2

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/702865837?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.



Re: iOS 14 / macOS 11 and HTTP/3 support

2020-06-28 Thread Luca Toscano
Hi Graham,

On Sun, Jun 28, 2020 at 12:53 PM Graham Leggett  wrote:
>
> On 27 Jun 2020, at 14:48, Luca Toscano  wrote:
>
> > the challenges are the same one discussed in your previous email
> > thread 
> > (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E).
> > I think that everybody would love to start working/helping on adding
> > HTTP/3 support but the work to be done is huge, involves invasive
> > changes to the httpd's source code and the current dev resources don't
> > have (rightfully) bandwidth to support the current codebase and plan a
> > major refactoring.
>
> I would be careful with wide reaching statements like this.

This is my opinion, supported by my understanding of the thread above,
that's it :). I am just trying to answer to the community with what I
think are the road blockers, please correct me where I am wrong.

> I’ve been working on identifying and removing blockers in various parts of 
> the httpd subsystems that prevent httpd to be cleanly event driven, and most 
> of those blockers have been removed.
>
> The underlying architecture of httpd is very strong, and would support new 
> protocols without too much trouble.

I don't think that my words implied anything against httpd, but in
case you feel in this way apologies. Even if httpd's source is very
strong and has been proven reliable during the years, it was visible
from the development of HTTP/2 that in order to support new protocols,
httpd would have needed to evolve in a significant way, and what I am
trying to say is that it needs resources and people time.

> The main point is that it must be done carefully and properly, but this is 
> not a reason to not do it at all.

Never said (I think) that it is not doable, only that there is a lot
of work to be done.

Luca


Re: iOS 14 / macOS 11 and HTTP/3 support

2020-06-28 Thread Graham Leggett
On 27 Jun 2020, at 14:48, Luca Toscano  wrote:

> the challenges are the same one discussed in your previous email
> thread 
> (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E).
> I think that everybody would love to start working/helping on adding
> HTTP/3 support but the work to be done is huge, involves invasive
> changes to the httpd's source code and the current dev resources don't
> have (rightfully) bandwidth to support the current codebase and plan a
> major refactoring.

I would be careful with wide reaching statements like this.

I’ve been working on identifying and removing blockers in various parts of the 
httpd subsystems that prevent httpd to be cleanly event driven, and most of 
those blockers have been removed.

The underlying architecture of httpd is very strong, and would support new 
protocols without too much trouble.

The main point is that it must be done carefully and properly, but this is not 
a reason to not do it at all.

Regards,
Graham
—



Re: iOS 14 / macOS 11 and HTTP/3 support

2020-06-28 Thread Luca Toscano
Hi,

On Sun, Jun 28, 2020 at 7:58 AM Helmut K. C. Tessarek
 wrote:
>
> On 2020-06-27 08:48, Luca Toscano wrote:
> > the challenges are the same one discussed in your previous email
> > thread
>
> These are all valid points, although in the end absolutely irrelevant.
>
> It's very easy and it doesn't take a genius to figure this out: as soon as
> there is a web server out there that can do HTTP/3, people will just use that
> one instead. All the excuses (even though I do understand how valid they are)
> won't change a thing.

there are already web servers doing HTTP/3, but the httpd project is
not in any "race" to get first to new features, this is not the way
Apache works. We will release HTTP/3 support when the development
community will be ready to deliver a strong and solid codebase, not
before. Supporting HTTP/3 is also a strong requirement that holds for
some use cases (for example, services that are directly Internet
facing), but does not for others (in case of HTTP/2, I am not aware of
a lot of people preferring it to HTTP when dealing with proxied
requests between services etc..).

Again, we welcome any contribution to reach the HTTP/3 goal, as stated
multiple times, since we consider it very important. On our side we'll
also try to do everything to keep supporting httpd and adding new
features in a timely manner (the former is not a simple thing to do
too, given the amount of users to support).

Luca


Bug report for Apache httpd-2 [2020/06/28]

2020-06-28 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|
|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)|
|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|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content |