Re: iOS 14 / macOS 11 and HTTP/3 support
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)
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 li
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
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)
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&utm_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_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)
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&utm_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_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
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&view=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&r1=1879305&r2=1879306&view=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&r1=1879305&r2=1879306&view=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&r1=1879305&r2=1879306&view=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&r1=1879305&r2=1879306&view=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 functio
Still Failing: apache/httpd#894 (trunk - 4a0c08e)
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&utm_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_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
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
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
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]
+---+ | 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 | |39748|