"2.0.52 : released September 28, 2005 as GA. " should be "2.0.52 : released September 28, 2004 as GA. "
On Wed, 8 Dec 2004 23:45:11 -0500, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: > APACHE 2.0 STATUS: -*-text-*- > Last modified at [$Date: 2004/11/10 18:05:46 $] > > Release: > > 2.0.53 : in development > 2.0.52 : released September 28, 2005 as GA. > 2.0.51 : released September 15, 2004 as GA. > 2.0.50 : released June 30, 2004 as GA. > 2.0.49 : released March 19, 2004 as GA. > 2.0.48 : released October 29, 2003 as GA. > 2.0.47 : released July 09, 2003 as GA. > 2.0.46 : released May 28, 2003 as GA. > 2.0.45 : released April 1, 2003 as GA. > 2.0.44 : released January 20, 2003 as GA. > 2.0.43 : released October 3, 2002 as GA. > 2.0.42 : released September 24, 2002 as GA. > 2.0.41 : rolled September 16, 2002. not released. > 2.0.40 : released August 9, 2002 as GA. > 2.0.39 : released June 17, 2002 as GA. > 2.0.38 : rolled June 16, 2002. not released. > 2.0.37 : rolled June 11, 2002. not released. > 2.0.36 : released May 6, 2002 as GA. > 2.0.35 : released April 5, 2002 as GA. > 2.0.34 : tagged March 26, 2002. > 2.0.33 : tagged March 6, 2002. not released. > 2.0.32 : released Feburary 16, 2002 as beta. > 2.0.31 : rolled Feburary 1, 2002. not released. > 2.0.30 : tagged January 8, 2002. not rolled. > 2.0.29 : tagged November 27, 2001. not rolled. > 2.0.28 : released November 13, 2001 as beta. > 2.0.27 : rolled November 6, 2001 > 2.0.26 : tagged October 16, 2001. not rolled. > 2.0.25 : rolled August 29, 2001 > 2.0.24 : rolled August 18, 2001 > 2.0.23 : rolled August 9, 2001 > 2.0.22 : rolled July 29, 2001 > 2.0.21 : rolled July 20, 2001 > 2.0.20 : rolled July 8, 2001 > 2.0.19 : rolled June 27, 2001 > 2.0.18 : rolled May 18, 2001 > 2.0.17 : rolled April 17, 2001 > 2.0.16 : rolled April 4, 2001 > 2.0.15 : rolled March 21, 2001 > 2.0.14 : rolled March 7, 2001 > 2.0a9 : released December 12, 2000 > 2.0a8 : released November 20, 2000 > 2.0a7 : released October 8, 2000 > 2.0a6 : released August 18, 2000 > 2.0a5 : released August 4, 2000 > 2.0a4 : released June 7, 2000 > 2.0a3 : released April 28, 2000 > 2.0a2 : released March 31, 2000 > 2.0a1 : released March 10, 2000 > > Please consult the following STATUS files for information > on related projects: > > * srclib/apr/STATUS > * srclib/apr-util/STATUS > * docs/STATUS > > Contributors looking for a mission: > > * Just do an egrep on "TODO" or "XXX" in the source. > > * Review the "PatchAvailable" bugs in the bug database. > Append a comment saying "Reviewed and tested". > > * Open bugs in the bug database. > > RELEASE SHOWSTOPPERS: > > PATCHES TO BACKPORT FROM 2.1 > [ please place file names and revisions from HEAD here, so it is easy to > identify exactly what the proposed changes are! ] > > *) mod_ssl: Fix an possible NULL pointer dereference in some configs. > http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=13182 > PR: 31848 > +1: jorton, wrowe, jim > > *) Allow for the use of --with-module=foo:bar where the ./modules/foo > directory is a local addition to the ./modules directory. > Assumes, of course, that the required files are in ./modules/foo, > but makes it easier to statically build "external" modules by > simply adding them to ./modules. > modules/config5.m4: 1.4 > +1: jim, jerenkrantz > +0: wrowe > (would rather see --with-module-lib=foo --enable-bar=shared syntax > to > support multiple libs, module modules. Might need to pass the > --with-module-lib=foo to ./buildconf instead.) > > *) several changes to improve logging of connection-oriented errors, > including > ap_log_cerror() API (needs minor bump in addition to changes below) > > http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c?r1=1.289&r2=1.291 > > http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.150&r2=1.151 > > http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_log.h?r1=1.46&r2=1.48 > +1: trawick > > *) mod_auth_ldap: Handle the inconsistent way in which the MS LDAP > library handles special characters. > http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12919 > PR 24437 > +1: minfrin, wrowe, jim > > *) Fix ap_save_brigade's handling of ENOTIMPL setaside functions. > > http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/util_filter.c?r1=1.100&r2=1.102 > PR: 31247 > +1: jorton > > *) mod_headers: Support {...}s tag for SSL variable lookup. > http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff > +1: jorton, trawick > nd: two comments: > (1) is the use of APR_ASCII_* ebcdic-safe? I.e. shouldn't we use the > native chars here and it will be converted later? (I'm not sure) > jorton: I have no idea, let an EBCDIC-er complain if it breaks? > trawick: seems that '\r' and '\n' are the better chars to check > for; this is not raw data read from the network (or directly > from SSL) but instead it is either protocol data that has > already been converted to the native charset or it is other > data which was created inside the server in the native charset > (2) I'd put out (null) only if val is NULL, not if it's empty. > jorton: ssl_var_lookup() returns "" in place of NULL, that was really > a deliberate choice... but maybe you're right. > > *) Remove LDAP toolkit specific code from util_ldap and mod_auth_ldap. > modules/experimental/mod_auth_ldap.c: 1.28 > modules/experimental/util_ldap.c: 1.36 > +0: minfrin (this requires the apr-util LDAP overhaul to be ported to > apr-util v0.9 first) > -0: jerenkrantz > jerenkrantz: I don't think we can change the APR 0.9 interfaces. > They are supposed to be set in stone. > -1: wrowe: agrees with jerenkrantz, further realized that this major > change in APR 1.0 caused -every- apr-util linked app to > have > the ldap sdk (openldap etc) linked in, and our > --static-support > stuff is horribly broken by this change. Not that it's > wrong, > we need to look at making it slightly more dynamic for > those > apps that don't touch ldap. > > *) Add load balancer support to the scoreboard in preparation for > load balancing support in mod_proxy. > include/scoreboard.h: 1.52 > server/scoreboard.c: 1.75 > +0: minfrin: it makes sense for v2.1 or v2.2 > -0: nd, jerenkrantz > nd: -0 as in "it should be considered as a 2.1 feature". > If the modified structures are public (are they?), I'm just -1. > jerenkrantz: Sounds like a good 2.1 feature... > -1: wrowe (make this a private score to the module and you would be > fine; > we don't need to keep overloading a single scoreboard.) > > *) mod_cgi: Added API call and overload of detached field in > cgi_exec_info_t > structure to support loading in current or new address space for CGIs. > The patch change how NetWare use cmdtype for processes. It was made > necessary by changes done to log.c r1.145. > The HTTP and the APR patches are available at: > <http://www.apache.org/~clar/detach-addrspace_HTTP_2_0.patch> > <http://www.apache.org/~clar/detach-addrspace_APR_0_9.patch> > +1: jjclar, bnicholes, trawick > trawick notes: some folks want feature checks for uses of new APR > functions in httpd 2.0; I dunno how to check for > availability of apr_procattr_addrspace_set() > > *) mod_ssl: Remove some unused functions (after CAN-2004-0488 fix is > applied) > > http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_util.c?r1=1.46&r2=1.47 > +1: jorton > trawick: need changes to mod_ssl.h to remove prototypes for those > removed functions > 0: nd: IMHO that's a public API change then and not applicable for > 2.0, just let 'em in > -1: wrowe (as nd suggests, leave the dead horse in peace.) > > *) mod_actions: Regression from 1.3: the file referred to must exist. > Solve this by introducing the "virtual" modifier to the Action > directive. PR 28553. > modules/mappers/mod_actions.c: r1.32, r1.34 > jerenkrantz: Icky side-effect of the *t == '0' check. > +1: nd, jerenkrantz, wrowe, jim > > *) mod_log_config: Cleanup log_header_out function to allow multiple > headers > like Set-Cookie to be logged properly. PR 27787 (2.0 + 1.3) > modules/loggers/mod_log_config.c: r1.116 > jerenkrantz asks: Isn't this what apr_table_merge is for? > nd replies: yep. But cookies won't be merged, because browsers don't > support it. > jerenkrantz: Couldn't we copy the table and merge the values somehow? > This just seems like a lot of code to duplicate what we > have already. *shrug* Regardless, patch looks okay... > +1: nd, jerenkrantz > > *) mod_dav: Send an EOS at the end of the multistatus brigade. > > http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/dav/main/mod_dav.c?r1=1.105&r2=1.106 > +1: jorton, jerenkrantz > nd asks: Sure, you want to drop the return code of ap_pass_brigade? > jerenkrantz: They already did drop it. Note that this really isn't > a correctness fix; just a perf. fix. We'd send the EOS > later without it. > > *) Provide TLS/SSL upgrade functionality in mod_ssl allowing an unsecure > connection to be upgraded to a secure connection upon request by the > client. The full patch file is available at > http://www.apache.org/~bnicholes/ > as well as a test client tlsupgrade.c. This functionality is mainly > used by > IPP clients today. > modules/ssl/mod_ssl.c: r1.75, r1.97, r1.100 > modules/ssl/mod_ssl.h: r1.123 > modules/ssl/ssl_engine_config.c: r1.71, r1.90 > modules/ssl/ssl_engine_init.c: r1.107, r1.126 > modules/ssl/ssl_engine_io.c: r1.102, r1.124 > modules/ssl/ssl_engine_kernel.c: r1.83, r1.105, r1.108 > modules/ssl/ssl_util.c: r1.36 > modules/ssl/ssl_private.h: r1.2 > +1: bnicholes, wrowe > -0: jerenkrantz (should wait for 2.2) > -0: jorton (msgid <[EMAIL PROTECTED]>) > > * Replace some of the mutex locking in the worker MPM with > atomic operations for higher concurrency. > server/mpm/worker/fdqueue.c 1.24, 1.25 > +1: brianp, ianh, jjclar > trawick: Doesn't this make Apache 2.0.next slower except > when the right atomic operations are available/ > implemented? (Due to under-the-covers mutex > operations when the dummy atomics are used?) > pquerna: Has anyone tested the performance differences > for different platforms? At this point I would > favour waiting for 2.2. > -0: stoddard (at least until the performance implications are clarified) > > * Rewrite how proxy sends its request to allow input bodies to > morph the request bodies. Previously, if an input filter > changed the request body, the original C-L would be sent which > would be incorrect. > > Due to HTTP compliance, we must either send the body T-E: chunked > or include a C-L for the request body. Connection: Close is not > an option. [jerenkrantz 2002/12/08 21:37:27] > +1: stoddard, striker, jim > -1: brianp (we need a more robust solution than what's in 2.1 right > now), > jerenkrantz (should be fixed, but I don't have time to do this) > > * Allow mod_dav to do weak entity comparison functions. > modules/dav/main/util.c: r1.45 > [ This one is under review. Don't merge. ] > +1: > > * mod_negotiation: parse quality values independent from > the current locale and level values as integers. PR 17564. > (essentially: get a rid of atof()) (2.0 + 1.3) > modules/mappers/mod_negotiation.c: r1.114 > +1: nd > We need to decide what happens with unparsable qvalues. RFC 2616 > states that q defaults to 1. (see 14.1 - 14.4). So should wrong > qvalues be returned as 1.0 or 0.0 (as atof() did)? > 1.0: nd > 0.0: jim (a default != an "errored" value) > > * Keep the same SSLMutex for the lifetime of the parent process > (instead of having children using different mutexes and failing > to lock the session cache across restarts.) > New patch forthcoming - JimJag's changes make the merge ugly. > +1: wrowe > +1 (concept): jim (final vote when the patch is available) > > * Fix the SSLMutex config parser so that all 'mechanisms' can take > a filename, even if ignored, and they are rooted to the full path > to the server (except for posixsem locks). This allows a very > cross-platform default:logs/ssl_mutex to be used everywhere. Also > eliminates the '.pid' suffix so that the name given is the name. > Allows Win32 and other non-unicies to use named locks. > New patch forthcoming - JimJag's changes make the merge ugly. > +1: wrowe > +1 (concept): jim (final vote when the patch is available) > > * mod_ssl: Drop SSL_EXPERIMENTAL_ENGINE test in favor of testing for the > ENGINE_init() function in config.m4, and use HAVE_ENGINE_INIT instead. > wrowe notes that this feature is a noop until configured with SSLEngine. > http://www.apache.org/~wrowe/have_engine_init.patch for a clean 2.0 > patch. > modules/ssl/README 1.40 > modules/ssl/config.m4 1.14 > modules/ssl/mod_ssl.c 1.79 > modules/ssl/mod_ssl.h 1.135 > modules/ssl/ssl_engine_config.c 1.78 > modules/ssl/ssl_engine_init.c 1.113 > modules/ssl/ssl_toolkit_compat.c 1.33 > +0: wrowe {Pending research into how to get AC to use -lsockets et. al., > shows breakage on Solaris which can't -lcrypto -lssl without > the extra pkgconfig/openssl.pc Libs: * foo } > > * mod_ssl: fix a link failure when the openssl-engine libraries are > present but the engine headers are missing. > modules/ssl/mod_ssl.c: r1.87 > modules/ssl/mod_ssl.h: r1.139 > modules/ssl/ssl_engine_config.c: r1.82 > PREREQ: Blow away of SSL_EXPERIMENTAL_ENGINE (see above) > +1: jwoolley, trawick, jim, jerenkrantz > > * When UseCanonicalName is set to OFF, allow ap_get_server_port to > check r->connection->local_addr->port before defaulting to > server->port or ap_default_port() > server/core.c r1.247 > +1: bnicholes, jim, wrowe > 0: nd, jerenkrantz > nd: can the local_addr->port ever be 0? > bnicholes response: I couldn't tell you for sure if local_addr->port > could be 0. But it makes sense that if it were then Apache > wouldn't be listening on any port so it wouldn't matter anyway. > nd replies: But if it can't be 0 the alternatives thereafter make no > sense anymore, right? > jim proposes: UseCanonicalName Client directive > which implements this, keeping UseCanonicalName Off > "as is". > > * ThreadStackSize for Win32 and threaded MPMs > (if there is sufficient interest I'll pursue getting APR 0.9 > fixed up as well as putting together a patch for httpd 2.0.next > which integrates the two rounds of changes) > +1 concept: trawick, nd, stoddard, wrowe > > * mod_cache: Add CacheIgnoreHeaders directive. > PR: 30399 > docs/manual/mod/mod_cache.xml: r1.18 > modules/experimental/cache_util.c: 1.36 > modules/experimental/mod_cache.c: 1.95 > modules/experimental/mod_cache.h: 1.52 > modules/experimental/mod_disk_cache.c: 1.67 > modules/experimental/mod_mem_cache.c: 1.119 > +1: jerenkrantz > +0: sounds like a nice 'feature' v.s. rfc-required behavior, great for > 2.2 > > CURRENT RELEASE NOTES: > > * Backwards compatibility is expected of future Apache 2.0 releases, > such that no MMN major number changes will occur until 2.1. > > * All commits to APACHE_2_0_BRANCH must be reflected in cvs HEAD > as well, if they apply. Logical progression is commit to HEAD, > get feedback and then commit to APACHE_2_0_BRANCH. > > CURRENT VOTES: > > * Promote mod_ldap and mod_auth_ldap from experimental to > non experimental status. > +1: bnicholes, wrowe > +0: minfrin (wait till the last cache bugs are ironed out) > > * Promote mod_cache from experimental to non-experimental > status (keep issues noted below in EXPERIMENTAL MODULES as > items to be addressed as a supported module). > +1: jim, stoddard, bnicholes, fielding, wrowe > > * Develop in Review-Then-Commit or Commit-Then-Review mode > on APACHE_2_0_BRANCH (no vetoes, this is a straight vote.) > R-T-C: trawick, wrowe, jerenkrantz, stoddard, rederpj, striker, nd, > gregames(lazy consensus OK for mainline), jwoolley > Abstain: > C-T-R: BrianP, aaron, jim, gstein, bnicholes, minfrin > > gstein: we have an open branch, so there is an easy release > valve for feature and API changes. we trust developers > to put their changes in the right place. if they > *don't*, that is what the -T-R is all about, and why we > have source control. > > yes, the branch should be "bug fix only" or other > voted-upon feature changes, but we already have > guidelines for all that. > > http://httpd.apache.org/dev/guidelines.html > > see the section titled "Product Changes" and the > following paragraph which states: > > "... All product changes to a prior-branch (old > version) repository require consensus before the change > is committed." > > And under "When to Commit a Change", first line: > > "Ideas must be review-then-commit; patches can be > commit-then-review." > > The problem here is that R-T-C expresses a fundamental > DISTRUST of your peers. We had problems stabilizing the > code simply because there are numerous interests in the > codebase, and those are not fully compatible. With the > branch, we have partitioned the interest: bug fix vs > new features. But developers *know* when a bug fix > should be applied or should not. There is no reason to > tell a developer they are wrong, and their basic > understanding of what is broken and what needs to be > fixed is subject to peer review. Once you have a bug > fix in hand, it isn't rocket science. And, always, > there is the option to pull a fix back out if a > developer goofs. We all goof, but there is no sense in > ASSUMING that incorrect behavior is the norm. > > If a develop consistently causes problems, then we have > ways of dealing with that. But at the moment, this > isn't the case, and it does not foster a healthy > environment to apply that label to ALL developers. > R-T-C is fundamentally "you're guilty of bad behavior, > with no way to prove innocence. all your actions are > hereby monitored." > > Why did I wait so long to issue this commentary? Simply > because I disagreed with it at such a fundamental level > that I didn't want to deal with it. Also, that I > *wasn't* going to deal with it when I had changes to > commit. But now we're seeing this stupid R-T-C hammer > being used to smack developers over the head. That is > inappropriate when the bug fixes they are committing to > the branch are entirely reasonable and appropriate. The > hammer simply should not exist. > > Yes, I'm ranting, and hey, I'm even sober. :-) R-T-C is > Badness. If I could veto the policy, I would. If I can > ignore it, I will. For years, this group was built on > the notion of peer respect and trust. R-T-C destroys > that, and makes the environment less cozy and less > inviting. Our polcies and procedures were designed to > operate successfully in a C-T-R environment; there is > no need for such a draconian policy. > > Bleh. > > minfrin: I see no point in adding any bureaucracy between a bug > and its fix. > > * httpd-std.conf and friends; > > a) httpd-std.conf should be tailored by install (from src or > binbuild) even if user has existing httpd.conf > +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, > erikabele > wrowe - prefer httpd.default.conf to avoid ambiguity with cvs, > note that win32 installer creates just that file > (.default.conf rather than .conf.default so that win32 > can recognize .conf files as text configuration files.) > > b) tailored httpd-std.conf should be copied by install to > sysconfdir/examples > -0: striker > > c) tailored httpd-std.conf should be installed to > sysconfdir/examples or manualdir/exampleconf/ > +1: slive, trawick, Ken, nd (prefer the latter), erikabele > > d) tailored httpd-std.conf should be installed as > httpd-std-<version>.conf. > +1: striker > > e) Installing a set of default config files when upgrading a server > doesn't make ANY sense at all. > +1: ianh - medium/big sites don't use 'standard config' anyway, as > it > usually needs major customizations > -1: Ken, wrowe, jwoolley, jim, nd, erikabele > wrowe - diff is wonderful when comparing old/new default configs, > even for customized sites that ianh mentions > jim - it makes sense assuming that the default configs > include the updated directives and inline comments > that explain the changes and make the 'diff' more useful. > > * If the parent process dies, should the remaining child processes > "gracefully" self-terminate. Or maybe we should make it a runtime > option, or have a concept of 2 parent processes (one being a > "hot spare"). > See: Message-ID: <[EMAIL PROTECTED]> > > Self-destruct: Ken, Martin > Not self-destruct: BrianP, Ian, Cliff, BillS > Make it runtime configurable: Aaron, Justin, wrowe, rederpj, jim, nd > > /* The below was a concept on *how* to handle the problem */ > Have 2 parents: +1: jim > -1: Justin, wrowe, rederpj, nd > +0: Martin (while standing by, could it do > something useful?) > > * Make the worker MPM the default MPM for threaded Unix boxes. > +1: Justin, Ian, Cliff, BillS, striker > +0: BrianP, Aaron (mutex contention is looking better with the > latest code, let's continue tuning and testing), rederpj, jim > -0: Lars, wrowe (let's make this defacto for the 2.2 release.), > nd (for 2.0) > > RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: > > * mod_ssl: We twiddle status bits rather than calling SSL_renegotiate > to unset the current negotiation status. This especially affects > sslc users who can't touch these internal bits (nor should OpenSSL > based apps do so.) Flipping to SSL_renegotiate causes us to start > failing perl-framework tests. Needs some further research. > http://www.apache.org/~wrowe/ssl_renegotiate.patch for a clean 2.0 > patch, > or for httpd-2.1 refer to: > modules/ssl/config.m4 1.15 > modules/ssl/ssl_engine_io.c 1.08 > modules/ssl/ssl_engine_kernel.c 1.93 > modules/ssl/ssl_toolkit_compat.c 1.34 > > * There is a bug in how we sort some hooks, at least the pre-config > hook. The first time we call the hooks, they are in the correct > order, but the second time, we don't sort them correctly. Currently, > the modules/http/config.m4 file has been renamed to > modules/http/config2.m4 to work around this problem, it should moved > back when this is fixed. > > OtherBill offers that this is a SERIOUS problem. We do not sort > correctly by the ordering arguments passed to the register hook > functions. This was proven when I reordered the open_logs hook > to attempt to open the error logs prior to the access logs. Possibly > the entire sorting code needs to be refactored. > > * pipes deadlock on all platforms with limited pipe buffers (e.g. both > Linux and Win32, as opposed to only Win32 on 1.3). The right solution > is either GStein's proposal for a "CGI Brigade", or OtherBill's proposal > for "Poll Buckets" for "Polling Filter Chains". Or perhaps both :-) > > * All handlers should always send content down even if r->header_only > is set. If not, it means that the HEAD requests don't generate the > same headers as a GET which is wrong. > > * HP/UX 10.20: compile breakage in APR. Looks like it should be easy > to fix, probably just some extraneous #include's that are fouling > things up. > PR: 9457 > Jeff: See my reply and patch in the PR (and previous commit to > stop using "pipe" as a field name). If patch is committed, we > should be okay. I'll wait to see if the user tests the patch. > Update by Jeff 20020722: I got an account on HP 10.20. It looks > like some of the APR thread detection is screwed up. If we find > pthread.h but we can't compile the pthread test program we still > think we can use threads. For that reason, the patch I posted > to the PR won't work as-is since a failed compile of the test > program means nothing. > > * exec cmd and suexec arg-passing enhancements > Status: Patches proposed > Message-ID: <[EMAIL PROTECTED]> > (see the "proc.patch" and "suexec-shell.patch" links in this message) > > * The 2.0.36 worker MPM graceless shutdown changes work but are > a bit clunky on some platforms; eg, on Linux, the loop to > join each worker thread seems to hang, and the parent ends up > killing off the child with SIGKILL. But at least it shuts down. > > * --enable-mods-shared="foo1 foo2" is busted on Darwin. Pier > posted a patch (Message-ID: <[EMAIL PROTECTED]>). > > * We do not properly substitute the prefix-variables in the configuration > scripts or generated-configs. (i.e. if sysconfdir is etc, > httpd-std.conf points to conf.) > > * If any request gets through ap_process_request_internal() and is > scheduled to be served by the core handler, without a flag that this > r->filename was tested by dir/file_walk, we need to 500 at the very > end of the ap_process_request_internal() processing so sub_req-esters > know this request cannot be run. This provides authors of older > modules better compatibility, while still improving the security and > robustness of 2.0. > > Status: still need to decide where this goes, OtherBill comments... > Message-ID: <[EMAIL PROTECTED]> > [Deleted comments regarding the ap_run_handler phase, as irrelevant > as BillS points out that "common case will be caught in > default_handler already (with the r->finfo.filetype == 0 check)" > and the issue is detecting this -before- we try to run the req.] > > gregames says: can this happen somehow without a broken module > being involved? If not, why waste cycles trying to defend against > potential broken modules? It seems futile. > wrowe counters: no, it shouldn't happen unless the module is broken. > But the right answer is to fail the request up-front in dir/file > walk if the path was entirely invalid; and we can't do that either > UNTIL 2.1 or we break modules that haven't hooked map_to_storage. > > * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me > how the Perchild MPM should be re-written. It hasn't worked > correctly since filters were added because it wasn't possible to > get the content that had already been written and the socket at > the same time. This mode lets us do that, so the MPM can be > fixed. > > * htpasswd blindly processes the file you give it, and does no > sanity checking before totally corrupting whatever file it was > you thought you had. It should check the input file and bail > if it finds non-comment lines that do not contain exactly 1 > ':' character. > Message-ID: <[EMAIL PROTECTED]> > > * Can a static httpd be built reliably? > Message-ID: <[EMAIL PROTECTED]> > > * [Ken] Test suite failures: > o worker is also failing some of the 'cgi' subtests > (see <URL:http://Source-Zone.Org/Apache/regression/>): > Justin says: "Worker should be fine and passes httpd-test here. > I think it's a perl or a httpd-test problem." > > * Usage of APR_BRIGADE_NORMALIZE in core_input_filter should be > removed if possible. > Message-ID: <[EMAIL PROTECTED]> > Jeff wonders if we still care about this. It is no longer an > API issue but simply an extra trip through the brigade. > > * The Add...Filter and Set...Filter directives do not allow the > administrator to order filters, beyond the order of filename (mime) > extensions. It isn't clear if Set...Filter(s) should be inserted > before or after the Add...Filter(s) which are ordered by sequence of > filename extensions. At minimum, some sort of +-[0-10] syntax seems > like a nice solution. See ROADMAP. > > * Get perchild to work on platforms other than Linux. This > will require a portable mechanism to pass data and file/socket > descriptors between vhost child groups. An API was proposed > on [EMAIL PROTECTED]: > Message-ID: <[EMAIL PROTECTED]> > > * Try to get libtool inter-library dependency code working on AIX. > Message-ID: <[EMAIL PROTECTED]> > > Justin says: If we get it working on AIX, we can enable this > on all platforms and clean up our build system > somewhat. > Jeff says: I thought I tested a patch for you sometime in > January that you were going to commit within a few > days. > > * Handling of %2f in URIs. Currently both 1.3 and 2.0 > completely disallow %2f in the request URI path (see > ap_unescape_url() in util.c). It's permitted and passed > through in the query string, however. Roy says the > original reason for disallowing it, from five years ago, > was to protect CGI scripts that applied PATH_INFO to > a filesystem location and which might be tricked by > ..%2f..%2f(...). We *should* allow path-info of the > form 'http://foo.com/index.cgi/path/to/path%2finfo'. > Since we've revamped a lot of our processing of path > segments, it would be nice to allow this, or at least > allow it conditionally with a directive. > > OtherBill adds that %2f as the SECOND character of a multibyte > sequence causes the request to fail! This happens notably in > the ja-jis encoding. > > OtherBill is -0.5 for even considering this until 2.2 because > it removes some protection we provided to third party modules > that would mysteriously 'evaporate', exposing potential holes > in security. Putting this change into 2.1 development now (with > strong warnings!) will give authors a chance to vet their code. > > * FreeBSD, threads, and worker MPM. All seems to work fine > if you only have one worker process with many threads. Add > a second worker process and the accept lock seems to be > lost. This might be an APR issue with how it deals with > the child_init hook (i.e. the fcntl lock needs to be resynced). > More examination and analysis is required. > Status: This has also been reported on Cygwin. > FreeBSD 4.7 was reputed to have 'fixed' threads. Not. > Message-ID: <[EMAIL PROTECTED]> (cygnus) > > Aaron says: I spent some time disecting this and have come to > the conclusion that it is not a problem in the worker MPM > (or at least, it is not isolated to a problem in worker). > I'll list some of the problems I'm seeing in case someone > else wants to pick up where I've left off: > - Delivery of just about any signal to one of the child > processes will send it into an infinite loop as well. > - Even though the parent is spinning out of control, > at first the child or children will appear to work > properly. At times it is possible to get it into a state, > however, where a request will hang until another concurrent > request "kicks" the first, at which point the second will > hang. My theory is that this has to do with the > pthread_cond_*() implementation in FreeBSD, but it's still > possible that it is in APR. > > Justin adds: Oh, FreeBSD threads are implemented entirely with > select()/poll()/longjmp(). Welcome to the nightmare. > So, that means a ktrace output also has the thread > scheduling internals in it (since it is all the same to > the kernel). Which makes it hard to distinguish between > our select() calls and their select() calls. > *bangs head on wall repeatedly* But, some of the libc_r > files have a DBG_MSG #define. This is moderately helpful > when used with -DNO_DETACH. The kernel scheduler isn't > waking up the threads on a select(). Yum. And, I bet > those decrementing select calls have to do with the > scheduler. Time to brush up on our OS fundamentals. > > * There is increasing demand from module writers for an API > that will allow them to control the server à la apachectl. > Reasons include sole-function servers that need to die if > an external dependency (e.g., a database) fails, et cetera. > Perhaps something in the (ever more abused) scoreboard? > > On the other hand, we already have a pipe that goes between > parent > and child for graceful shutdown events, along with an API that > can be used to send a message down that pipe. In threaded MPMs, > it is easy enough to make that one pipe be used for graceful > and graceless events, and it is also easy to open that pipe > to both parent and child for writing. Then we just need to > figure out how to do graceless on non-threaded MPMs. > > * Win32: Rotatelogs sometimes is not terminated when Apache > goes down hard. FirstBill was looking at possibly tracking the > child's-child processes in the parent process. > stoddard: Shared scoreboard might offer a good way for the parent > to keep track of 'other child' processes and whack them if the child > goes down. > Other thoughts on walking the process chain using the NT kernel > have also been proposed on APR. > > * Eliminate unnecessary creation of pipes in mod_cgid > > * Combine log_child and piped_log_spawn. Clean up http_log.c. > Common logging API. > > * There are still a number of places in the code where we are > losing error status (i.e. throwing away the error returned by a > system call and replacing it with a generic error code) > > * Mass vhosting version of suEXEC. > > * All DBMs suffer from confusion in support/dbmmanage (perl script) since > the dbmmanage employs the first-matched dbm format. This is not > necessarily the library that Apache was built with. Aught to > rewrite dbmmanage upon installation to bin/ with the proper library > for predictable mod_auth_dbm administration. > Questions; htdbm exists, time to kill dbmmanage, or does it remain > useful as a perl dbm management example? If we keep it, > do we address the issue above? > > * Integrate mod_dav. > Some additional items remaining: > - case_preserved_filename stuff > (use the new canonical name stuff?) > - find a new home for ap_text(_header) > - is it possible to remove the DAV: namespace stuff from util_xml? > > * ap_core_translate() and its use by mod_mmap_static and mod_file_cache > are a bit wonky. The function should probably be exposed as a utility > function (such as ap_translate_url2fs() or ap_validate_fs_url() or > something). Another approach would be a new hook phase after > "translate" which would allow the module to munge what the > translation has decided to do. > Status: Greg +1 (volunteers) > > * Explore use of a post-config hook for the code in http_main.c which > calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and > ap_sort_hooks() [to reduce the logic in main()] > > * read the config tree just once, and process N times (as necessary) > OtherBill adds that the 'good' solution of three passes against the > config tree within one read is the better solution, but breaks many > modules. Best left for 2.2? > -0.5: OtherBill > > * (possibly) use UUIDs in mod_unique_id and/or mod_usertrack > > * (possibly) port the bug fix for PR 6942 (segv when LoadModule is put > into a VirtualHost container) to 2.0. > > * shift stuff to mod_core.h > > * callers of ap_run_create_request() should check the return value > for failure (Doug volunteers) > > * Win32: Get Apache working on Windows 95/98. The following work > (at least) needs to be done: > - Document warning that OSR2 is required (for Crypt functions, in > rand.c, at least.) This could be resolved with an SSL library, or > randomization in APR itself. > - Bring the Win9xConHook.dll from 1.3 into 2.0 (no sense till it > actually works) and add in a splash of Win9x service code. > > * Fix the worker MPM to use POD to kill child processes instead > of ap_os_killpg, regardless of how they should die. > > * Scoreboard structures could be changed in the future such that > proper alignment is not maintained, leading to segfaults on > some systems. Cliff posted a patch to deal with this issue but > later recanted. See this message to [EMAIL PROTECTED]: > Message-ID: <[EMAIL PROTECTED] > .cs.virginia.edu> > > TODO ISSUES REMAINING IN MOD_SSL: > > * In order to use a DSO version of mod_ssl we have to link with > -lssl and -lcrypto. A workaround is in place right now where the > entire EXTRA_LIBS macro is being appended to the objects list, but > this is a hack. We should either revamp the APACHE_CHECK_SSL_TOOLKIT > autoconf function or come up with some other autoconf checks to > search for libssl and libcrypto and properly add them to mod_ssl's > link flags. > > * SSL renegotiations in combination with POST request > > * Port or dispose all code inside #if 0...#endif blocks that remain > from the porting effort. > > * Do we need SSL_set_read_ahead()? > > * the ssl_expr api is NOT THREAD SAFE. race conditions exist: > -in ssl_expr_comp() if SSLRequire is used in .htaccess > (ssl_expr_info is global) > -is ssl_expr_eval() if there is an error > (ssl_expr_error is global) > > * SSLRequire directive (parsing of) leaks memory > > * Diffie-Hellman-Parameters for temporary keys are hardcoded in > ssl_engine_dh.c, while the comment in ssl_engine_kernel.c says: > "it is suggested that keys be changed daily or every 500 > transactions, and more often if possible." > > * ssl_var_lookup could be rewritten to be MUCH faster > > * CRL callback should be pluggable > > * session cache store should be pluggable > > * init functions should return status code rather than ssl_die() > > * ssl_engine_pphrase.c needs to be reworked so it is generic enough > to also decrypt proxy keys > > * the shmcb code should just align its memory segment rather than > jumping through all the "safe" memcpy and memset hoops > > EXPERIMENTAL MODULES: > > Experimental modules should eventually be be promoted to fully supported > status or removed from the repository entirely (ie, the 'experiment' > failed). This section tracks what needs to happen to get the modules > promoted to fully supported status. > > mod_cache/mod_mem_cache/mod_disk_cache: > * mod_cache: handle cache_control: no_cache "field_name" to enable > cacheing the response w/o header "field_name" > See RFC2616 section 14.9.1 > > * mod_cache: CacheEnable/CacheDisable should accept regular expressions. > > * mod_cache: Fix dependency on ATOMIC operators. Need > APR_HAS_ATOMIC_* feature macros. > > * mod_disk_cache: Implement garbage collection > > * mod_mem_cache/mod_disk_cache: Need to be able to query cache > status (num of entries, cache object properties, etc.). > mod_status could be extended to query optional hooks defined > by modules for the purpose of reporting module status. > mod_cache (et. al.) could define optional hooks that are called > to collect status. Status should be queryable by > HTTP or SNMP? > > * Enable mod_cache/mod_mem_cache/mod_disk_cache to handle > multiviews > > * mod_mem_cache/mod_disk_cache: Complete implementing config > directives (mod_disk_cache: CacheExpiryCheck and GC directives > including CacheGc*, CacheSize, and, CacheTimeMargin) > (mod_mem_cache: MCacheMaxObjectCount) and > (mod_cache: CacheForceCompletion). > > * Fix RFC 2616 compliance issues. Including PRs: 15852, 15866, > 15868, 15869, 15870, 16133, 16135, 16136, 16521, 19441. > > mod_auth_ldap/util_ldap: > * General stabilization and testing > > * Fix the shared memory cache > > PRs that have been suspended forever waiting for someone to > put them into 'the next release': > > * documentation and Q&A > > PR#2221: Make online documentation search link back to my installation > Status: > > PR#2906: Propose that Apache recommend $UNIQUE_ID for all "session id" > algorithms > Status: > > PR#2793: When will Apache support P3P? Any Plans? > Status: > > * build > > PR#2113: HTTP Server Rebuild Line Needs Changing for the better > Status: > > PR#2421: problem specifying ndbm library for build ?with autoconfigure > Status: > > * config > > PR#76: missing call to "setlocale();" > Status: > > PR#628: Request of "Options SymLinksIfGroupMatch" > Status: > > PR#793: RLimitCPU and RLimitMEM don't apply to all children like they > should > Status: > > PR#922: it is useful to allow specifiction that root-owned symlinks > should always be followed > Status: > > PR#1028: DoS attacks involving memory consumption > Status: > > PR#1191: setlogin() is not called, causing problems with e.g. identd > Status: > > PR#1204: regerror() exists, use it > Status: > > PR#2284: Can not POST to ErrorDocument - Apache/1.3b6 > Status: > > PR#2396: Proposal for TimeZone directive > Status: > > PR#2446: AllowOverride FileInfo is too coarse > Status: > > PR#2760: [PATCH] User/Group for <Directory> and <Location> i.e. not only > in global and <Virtual>. > Status: > > PR#2907: suggestion: power up your Include directive :) > Status: > > PR#3018: cannot limit some HTTP methods > Status: > > PR#3677: New ErrorDocumentMatch directive > Status: > > PR#4244: "Files" and "FilesMatch" regexp does not recognize bang as > negation operator > Status: > > PR#5993: AllowOverride should have a 'CheckNone' and 'AllowNone' > argument > instead of only 'None' > Status: > > * mod_access > > PR#537: mod_access syntax allows hosts that should be restricted > Status: > > PR#1287: add allow,deny/deny,allow warning to mod_access > Status: > > PR#2512: <IfDenied> directive wanted > Status: > > * mod_auth-any > > PR#557: ~UserHome directories are not honored in absolute pathname > requests (.htaccess) > Status: > > PR#1117: Using NIS passwd.byname dbm files with AuthDBMUserFile > Status: > > PR#1809: Suggestion for improving authentication modules and core source > code, problem with 401 and ErrorDocument > Status: > > * mod_autoindex > > PR#1263: Add frame-safe anchor attribute to mod_autoindex links > Status: > > * mod_cgi (and suexec) > > PR#921: suexec Uses cwd before filling it in, doesn't use syslog > Status: > > PR#1176: Apache cannot handle continuation line in headers > Status: > > PR#1120: suexec does not parse arguments to #exec cmd > Status: > > PR#1268: CGI scripts running as Apache user: security (suexec etc.) > Status: > > PR#1285: Error messages could be easier to spot in cgi.log file for > suexec.c > Status: > > PR#1905: suexec - Allow modules to set user:group for execution. > Status: > > PR#2360: suexec for general access of user content? > Status: > > PR#2460: TimeOut applies to output of CGI scripts > Status: > > PR#2573: CGI's for general use still have to be run as another user > with suExec > Status: > > PR#4241: Need to be able to override shebang line to make CGI scripts > more portable. > Status: > > PR#4490: mod_cgi prevents handling of OPTIONS requests > Status: > > * mod_env > > PR#370: Modified PATH environemnt variable is not passed, instead > system's is used > Status: > > * mod_headers > > PR#1383: I make mod_headers to modify request headers as well as > response ones. > Status: > > PR#1677: mod_headers should allow mod_log_config-style formats in > header values > Status: > > * mod_imap > > PR#759: imap should read <MAP><AREA>*</MAP> too! > Status: > > * mod_include > > PR#78: Additional status for XBitHack directive > Status: > > PR#623: A smarter "Last Modified" value for SSI documents (see PR > number 600) > Status: > > PR#1145: mod_include > Allow for Last-Modified: without resorting to XBitHack > Status: > > PR#1803: patches to mod_include to allow for file tests > Status: > > PR#4459: Suggestion for better handling of Last-modified headers > Status: > > * mod_info > > PR#2415: /server-info doesn't check for the virtual host to list the > info > Status: > > * mod_log-any > > PR#1050: Logging of virtual server to error_log as well > Status: > > PR#1358: Selective url-encode of log fields (or maybe a pseudo > log_rewrite module?) > Status: > > PR#2073: pipelined connections are not logged correctly > Status: > > PR#4448: Please allow CGI env variables (QUERY_STRING, ...) to be logged > with %{}e > Status: > > * mod_negotiation > > PR#3191: no way to set global quality-of-source (qs) coneg values > with multiviews > Status: > > * mod_proxy > > PR#362: Mod_proxy doesn't allow change of error pages > Status: > > PR#440: Proxy doesn't deliver documents if not connected > Status: > > PR#534: proxy converts ~name to %7Ename when name starts with a dot (.) > Status: > > PR#612: Proxy FTP Authentication Fails > Status: > > PR#700: Proxy doesn't do links right for OpenVMS files through ftp: > Status: > > PR#980: Controlling Access to Remote Proxies would be nice... > Status: > > PR#994: Adding authentication "on the fly" through the proxy module > Status: > > PR#1085: ProxyRemote make a dead cycle. > Status: > > PR#1166: ``nph-'' not honored (no buffering) for ProxyRemote mapping > Status: > > PR#1290: Need to know "hit-rate" on proxy cache > Status: > > PR#1532: Proxy transfer logging > Status: > > PR#1547: No HTTP_X_FORWARDED_FOR set... > Status: > > PR#1567: ProxyRemote proxy requests fail authentication by firewall > Status: > > PR#1702: mod_proxy to support persistent conns? > Status: > > PR#1878: listing of proxy cache content > Status: > > PR#2314: patterns in ProxyRemote > Status: > > PR#2648: Cache file names in Proxy module > Status: > > PR#3568: Accessing URL through proxy server corrupts data. > Status: > > PR#3605: Some anonymous FTP URLs ask for authentication > Status: > > * mod_rewrite > > PR#1582: mod_rewrite forms REQUEST_URI different than mod_cgi does > Status: > > PR#2074: mod_rewrite doesn't pass Proxy Throughput on internal > subrequests > Status: > > * mod_status > > PR#2138: mod_status always displays 256 possible connection slots > Status: > > PR#2343: Status module averages are for entire uptime > Status: > > * apache-api > > PR#1004: request_config field in request_rec is moderately bogus > Status: > > PR#1158: improvements to child spawning API > Status: > > PR#1233: there is no way to keep per-connection per-module state > Status: > > PR#2024: adding auth_why to conn_rec > Status: > > PR#2873: Feedback/Comment on APACI > Status: > > PR#3143: No module specific data hook for per-connection data > Status: > > * generally odds and ends > > PR#2431: A small addition to rotatelogs.c to improve program > functionality. > Status: > > PR#2763: mailto tags and bundling bug report script > Status: > > PR#2785: os-aix Support for System Resource Controller > Status: > > PR#2889: Inclusion of RPM spec file in CVS/distributions > Status: > > PR#5713: os-windows [PATCH] install as win32 service with domain account > Status: Cannot accept password-as-arg, we should prompt the > user when -k install/-k config with a user argument. > > Other bugs that need fixing: > > * ap_discard_request should be converted to use the bucket API > directly rather than waste cycles copying buffers with the old API. > > * MaxRequestsPerChild measures connections, not requests. > Until someone has a better way, we'll probably just rename it > "MaxConnectionsPerChild". > > * Regex containers don't work in an intutive way > Status: No one has come up with an efficient way to fix this > behavior. Dean has suggested getting rid of regex containers > completely. > OtherBill suggests: We at least seem to agree on eliminating > the <Container ~ foo> forms, and using only > <ContainerMatch foo> semantics. > > * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a > sigwaiting thread. We need to work around this, perhaps unless > there is hope soon for a fixed glibc. > > * orig_ct in the byterange/multipart handling may not be > needed. Apache 1.3 just never stashed "multipart" into > r->content_type. We should probably follow suit since the > byterange stuff doesn't want the rest of the code to see the > multipart content-type; the other code should still think it is > dealing with the <orig_ct> stuff. > Status: Greg volunteers to investigate (esp. since he was most > likely the one to break it :-) > > Binaries (2.0.52): > > Platform Avail. Volunteer > ------------------------------------------------------------------ > AIX 4.3.3 no Bill Stoddard > Mandrake 8.1 no open > FreeBSD 4.1 no open > hppa2.0w-hp-hpux11.00 no Cliff Woolley > i386-pc-solaris2.9 no Aaron Bannert > i386-unknown-freebsd4.5 no > i386-unknown-freebsd4.6 no Cliff Woolley > i386-unknown-freebsd4.10 no Aaron Bannert > i686-pc-linux-gnu-slackware81 no Cliff Woolley > i686-pc-linux-gnu-rh70 no Aaron Bannert > i686-pc-linux-gnu-rh73 no Cliff Woolley > i686-pc-linux-gnu no Graham Leggett > ia64-hp-hpux11.20 no > powerpc-apple-darwin7.4.0 no Aaron Bannert > powerpc-unknown-linux-gnu no Graham Leggett > s390-ibm-linux no Greg Ames > sparc-sun-solaris2.8 no Jim Jagielski > NetWare no Brad Nicholes > OS/2 no Brian Havard > OS/390 no Greg Ames > Win32-x86 yes William Rowe > x86_64-unknown-linux-gnu no Aaron Bannert > -- In doG We Trust http://www.hutuworm.org
