1516N/AAPACHE 2.1 STATUS: -*-text-*-
39N/ALast modified at [$Date$]
39N/AThe current version of this file can be found at:
39N/ADocumentation status is maintained seperately and can be found at:
39N/AConsult the following STATUS files for information on related projects:
39N/APatches considered for backport are noted in their branches' STATUS:
342N/A 2.1.6 : Released on 6/27/2005 as alpha.
1516N/A 2.1.5 : Tagged on 6/17/2005.
1386N/A 2.1.3 : Released on 2/22/2005 as alpha.
2639N/A 2.1.2 : Released on 12/08/2004 as alpha.
2639N/A 2.1.1 : Released on 11/19/2004 as alpha.
39N/A 2.1.0 : not released.
2144N/AContributors looking for a mission:
1231N/A * Just do an egrep on "TODO" or "XXX" in the source.
296N/A * Review the "PatchAvailable" bugs in the bug database:
2690N/A After testing, you can append a comment saying "Reviewed and tested".
2690N/A * Open bugs in the bug database.
2690N/A * Handling of non-trailing / config by non-default handler is broken
2690N/A jerenkrantz asks: Why should this block a release?
2690N/A wsanchez agrees: this may be a change in behavior, but isn't
2690N/A clearly wrong, and even if so, it doesn't seem like a
2690N/A * the edge connection filter cannot be removed
2690N/A jerenkrantz asks: Why should this block a release?
2690N/A stas replies: because it requires a rewrite of the filters stack
2690N/A implementation (you have suggested that) and once 2.2 is
2690N/A released you can't do that anymore.
2690N/A +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd,
39N/A +1: slive, trawick, Ken, nd (prefer the latter), erikabele
39N/A d) Installing a set of default config files when upgrading a server
39N/A doesn't make ANY sense at all.
39N/A +1: ianh -
medium/big sites don't use 'standard config' anyway, as it
39N/A usually needs major customizations
39N/A -1: Ken, wrowe, jwoolley, jim, nd, erikabele
39N/A wrowe - diff is wonderful when comparing
old/new default configs,
39N/A even for customized sites that ianh mentions
39N/A jim - ... assuming that the default configs have been updated
39N/A with the required inline docs to explain the
39N/A * If the parent process dies, should the remaining child processes
39N/A "gracefully" self-terminate. Or maybe we should make it a runtime
39N/A option, or have a concept of 2 parent processes (one being a
39N/A See: Message-ID: <3C58232C.FE91F19F@Golux.Com>
39N/A Self-destruct: Ken, Martin, Lars
39N/A Not self-destruct: BrianP, Ian, Cliff, BillS
39N/A Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
48N/A /* The below was a concept on *how* to handle the problem */
48N/A Have 2 parents: +1: jim
48N/A -1: Justin, wrowe, rederpj, nd
48N/A +0: Lars, Martin (while standing by, could it do
48N/A * Make the worker MPM the default MPM for threaded Unix boxes.
2073N/A +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
2073N/A +0: BrianP, Aaron (mutex contention is looking better with the
39N/A latest code, let's continue tuning and testing), rederpj, jim
2639N/A pquerna: Do we want to change this for 2.2?
838N/ARELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
2608N/A * Patches submitted to the bug database:
39N/A * Filter stacks and subrequests, redirects and fast redirects.
1431N/A There's at least one PR that suffers from the current unclean behaviour
1431N/A (which lets the server send garbage): PR 17629
39N/A nd says: Every subrequest should get its own filter stack with the
227N/A subreq_core filter as bottom-most. That filter does two things:
315N/A - redirect the data stream to the upper request's (rr->main)
39N/A filter chain directly after the subrequest's starting
1352N/A Once we have a clean solution, we can try to optimize
1352N/A it, so that the server won't be slow down too much.
429N/A Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
315N/A 15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
1352N/A 16138, 16139, 16140, 16142, 16518, 16520, 16521,
429N/A jerenkrantz says: need to decide how many we need to backport
and/or 1352N/A if these rise to showstopper status.
1352N/A wrowe suggests: it would be nice to see "MUST"
v.s. "SHOULD"
v.s. "MAY"
39N/A out of this list, without reviewing them individually.
926N/A * There is a bug in how we sort some hooks, at least the pre-config
203N/A hook. The first time we call the hooks, they are in the correct
203N/A order, but the second time, we don't sort them correctly. Currently,
72N/A OtherBill offers that this is a SERIOUS problem. We do not sort
72N/A correctly by the ordering arguments passed to the register hook
59N/A functions. This was proven when I reordered the open_logs hook
2054N/A to attempt to open the error logs prior to the access logs. Possibly
1045N/A the entire sorting code needs to be refactored.
1045N/A * pipes deadlock on all platforms with limited pipe buffers (
e.g. both
1045N/A Linux and Win32, as opposed to only Win32 on 1.3). The right solution
1713N/A is either GStein's proposal for a "CGI Brigade", or OtherBill's proposal
1045N/A for "Poll Buckets" for "Polling Filter Chains". Or maybe both :-)
1045N/A * All handlers should always send content down even if r->header_only
2084N/A is set. If not, it means that the HEAD requests don't generate the
2084N/A same headers as a GET which is wrong.
2084N/A * exec cmd and suexec arg-passing enhancements
2084N/A Message-ID: <20020526041748.A29148@prodigy.Redbrick.DCU.IE>
838N/A * The 2.0.36 worker MPM graceless shutdown changes work but are
72N/A a bit clunky on some platforms; eg, on Linux, the loop to
72N/A join each worker thread seems to hang, and the parent ends up
2084N/A killing off the child with SIGKILL. But at least it shuts down.
72N/A * --enable-mods-shared="foo1 foo2" is busted on Darwin. Pier
59N/A posted a patch (Message-ID: <B8DBBE8D.575A%pier@betaversion.org>).
2639N/A * We do not properly substitute the prefix-variables in the configuration
59N/A scripts or generated-configs. (
i.e. if sysconfdir is etc,
72N/A * If any request gets through ap_process_request_internal() and is
72N/A scheduled to be served by the core handler, without a flag that this
2144N/A end of the ap_process_request_internal() processing so sub_req-esters
72N/A know this request cannot be run. This provides authors of older
59N/A modules better compatibility, while still improving the security and
72N/A Status: still need to decide where this goes, OtherBill comments...
72N/A Message-ID: <065701c14526$495203b0$96c0b0d0@roweclan.net>
59N/A [Deleted comments regarding the ap_run_handler phase, as irrelevant
72N/A as BillS points out that "common case will be caught in
2639N/A and the issue is detecting this -before- we try to run the req.]
2639N/A gregames says: can this happen somehow without a broken module
2639N/A being involved? If not, why waste cycles trying to defend against
59N/A potential broken modules? It seems futile.
1713N/A wrowe counters: no, it shouldn't happen unless the module is broken.
59N/A But the right answer is to fail the request up-front in
dir/file 838N/A walk if the path was entirely invalid; and we can't do that either
2240N/A UNTIL 2.1 or we break modules that haven't hooked map_to_storage.
838N/A * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me
838N/A how the Perchild MPM should be re-written. It hasn't worked
926N/A correctly since filters were added because it wasn't possible to
838N/A get the content that had already been written and the socket at
838N/A the same time. This mode lets us do that, so the MPM can be
2284N/A * Can a static httpd be built reliably?
2240N/A Message-ID: <20020207142751.T31582@clove.org>
2240N/A * Usage of APR_BRIGADE_NORMALIZE in core_input_filter should be
2240N/A Message-ID: <Pine.LNX.4.33.0201202232430.318-100000@deepthought.cs.virginia.edu>
2240N/A Jeff wonders if we still care about this. It is no longer an
2240N/A API issue but simply an extra trip through the brigade.
2240N/A * Get perchild to work on platforms other than Linux. This
2240N/A descriptors between vhost child groups. An API was proposed
2240N/A Message-ID: <20020111115006.K1529@clove.org>
2240N/A * Try to get libtool inter-library dependency code working on AIX.
2240N/A Message-ID: <cm3n10lx555.fsf@rdu163-40-092.nc.rr.com>
2240N/A Justin says: If we get it working on AIX, we can enable this
2240N/A on all platforms and clean up our build system
2240N/A Jeff says: I thought I tested a patch for you sometime in
2240N/A January that you were going to commit within a few
2284N/A * Handling of %2f in URIs. Currently both 1.3 and 2.0
2284N/A completely disallow %2f in the request URI path (see
2240N/A through in the query string, however. Roy says the
2240N/A original reason for disallowing it, from five years ago,
2284N/A was to protect CGI scripts that applied PATH_INFO to
2284N/A a filesystem location and which might be tricked by
2284N/A ..%2f..%2f(...). We *should* allow path-info of the
838N/A Since we've revamped a lot of our processing of path
838N/A segments, it would be nice to allow this, or at least
838N/A allow it conditionally with a directive.
838N/A OtherBill adds that %2f as the SECOND character of a multibyte
838N/A sequence causes the request to fail! This happens notably in
838N/A * FreeBSD, threads, and worker MPM. All seems to work fine
838N/A if you only have one worker process with many threads. Add
838N/A a second worker process and the accept lock seems to be
838N/A lost. This might be an APR issue with how it deals with
838N/A the child_init hook (
i.e. the fcntl lock needs to be resynced).
838N/A More examination and analysis is required.
845N/A Status: Works with FreeBSD 5.3. Does not work in previous versions.
845N/A This has also been reported on Cygwin.
838N/A * There is increasing demand from module writers for an API
845N/A that will allow them to control the server � la apachectl.
845N/A Reasons include sole-function servers that need to die if
845N/A an external dependency (
e.g., a database) fails, et cetera.
838N/A Perhaps something in the (ever more abused) scoreboard?
845N/A On the other hand, we already have a pipe that goes between parent
838N/A and child for graceful shutdown events, along with an API that
926N/A can be used to send a message down that pipe. In threaded MPMs,
203N/A it is easy enough to make that one pipe be used for graceful
315N/A and graceless events, and it is also easy to open that pipe
838N/A to both parent and child for writing. Then we just need to
203N/A figure out how to do graceless on non-threaded MPMs.
48N/A * Allow the DocumentRoot directive within <Location > scopes? This
48N/A and in-your-face.) DocumentRoot unset would be accepted [and would
838N/A not permit content to be served, only virtual resources such as
203N/A server-info or server-status.
48N/A This proposed change would _not_ depricate Alias.
203N/A striker: See the thread starting with Message-ID:
72N/A JLEGKKNELMHCJPNMOKHOGEEJFBAA.striker@apache.org.
72N/A * Win32: Rotatelogs sometimes is not terminated when Apache
181N/A goes down hard. FirstBill was looking at possibly tracking the
46N/A child's-child processes in the parent process.
181N/A stoddard: Shared scoreboard might offer a good way for the parent
237N/A to keep track of 'other child' processes and whack them if the child
2453N/A Other thoughts on walking the process chain using the NT kernel
2453N/A have also been proposed on APR.
2453N/A * Eliminate unnecessary creation of pipes in mod_cgid
2453N/A * Platforms that do not support fork (primarily Win32 and AS/400)
2453N/A Architect start-up code that avoids initializing all the modules
2339N/A in the parent process on platforms that do not support fork.
2339N/A * There are still a number of places in the code where we are
2339N/A losing error status (
i.e. throwing away the error returned by a
2339N/A system call and replacing it with a generic error code)
2453N/A * Mass vhosting version of suEXEC.
2453N/A the dbmmanage employs the first-matched dbm format. This is not
2453N/A necessarily the library that Apache was built with. Aught to
2453N/A rewrite dbmmanage upon installation to bin/ with the proper library
2453N/A for predictable mod_auth_dbm administration.
2453N/A Questions; htdbm exists, time to kill dbmmanage, or does it remain
2453N/A useful as a perl dbm management example? If we keep it,
2453N/A do we address the issue above?
2339N/A Some additional items remaining:
2453N/A - case_preserved_filename stuff
2453N/A (use the new canonical name stuff?)
2453N/A - find a new home for ap_text(_header)
2453N/A - is it possible to remove the DAV: namespace stuff from util_xml?
2453N/A * ap_core_translate() and its use by mod_mmap_static and mod_file_cache
2453N/A are a bit wonky. The function should probably be exposed as a utility
2453N/A function (such as ap_translate_url2fs() or ap_validate_fs_url() or
2453N/A something). Another approach would be a new hook phase after
2453N/A "translate" which would allow the module to munge what the
2453N/A translation has decided to do.
2453N/A Status: Greg +1 (volunteers)
2453N/A calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and
2453N/A ap_sort_hooks() [to reduce the logic in main()]
2453N/A * read the config tree just once, and process N times (as necessary)
2453N/A * (possibly) use UUIDs in mod_unique_id
and/or mod_usertrack
2453N/A * (possibly) port the bug fix for PR 6942 (segv when LoadModule is put
2453N/A into a VirtualHost container) to 2.0.
2453N/A * callers of ap_run_create_request() should check the return value
2453N/A for failure (Doug volunteers)
2339N/A * Win32: Get Apache working on Windows 95/98. The following work
2339N/A (at least) needs to be done:
2339N/A - Document warning that OSR2 is required (for Crypt functions, in
2339N/A rand.c, at least.) This could be resolved with an SSL library, or
2453N/A randomization in APR itself.
2453N/A actually works) and add in a splash of Win9x service code.
2453N/A * Fix the worker MPM to use POD to kill child processes instead
2339N/A of ap_os_killpg, regardless of how they should die.
2453N/A * Scoreboard structures could be changed in the future such that
2453N/A proper alignment is not maintained, leading to segfaults on
2453N/A some systems. Cliff posted a patch to deal with this issue but
2339N/A later recanted. See this message to dev@apr.apache.org:
2453N/A * APXS either needs to be fixed completely for use when apr is out of tree,
2453N/A or it should drop query mode altogether, and we just grow an
2339N/A httpd-config or similar arrangement.
2339N/A To quote a discussion in STATUS earlier:
2339N/A thommay: this doesn't fix all the problems with apxs and out of
2608N/A query cases; but I'm beginning to think that in these cases
2608N/A the app should be querying ap{r,u}-config directly
2608N/A gstein: agreed. apxs should deprecate the -q flag
2339N/A pquerna: I vote for a httpd-config, and to deprecate the -q flag.
2453N/A minfrin: +1 for httpd-config, and to deprecate -q.
2453N/ATODO ISSUES REMAINING IN MOD_SSL:
2540N/A * In order to use a DSO version of mod_ssl we have to link with
2339N/A -lssl and -lcrypto. A workaround is in place right now where the
2339N/A entire EXTRA_LIBS macro is being appended to the objects list, but
2339N/A this is a hack. We should either revamp the APACHE_CHECK_SSL_TOOLKIT
2339N/A autoconf function or come up with some other autoconf checks to
2339N/A search for libssl and libcrypto and properly add them to mod_ssl's
2339N/A * SSL renegotiations in combination with POST request
2339N/A * Port or dispose all code inside #if 0...#endif blocks that remain
2453N/A * Do we need SSL_set_read_ahead()?
2453N/A * the ssl_expr api is NOT THREAD SAFE. race conditions exist:
2453N/A -in ssl_expr_comp() if SSLRequire is used in .htaccess
2453N/A -is ssl_expr_eval() if there is an error
2608N/A * SSLRequire directive (parsing of) leaks memory
2453N/A * Diffie-Hellman-Parameters for temporary keys are hardcoded in
2453N/A "it is suggested that keys be changed daily or every 500
2453N/A transactions, and more often if possible."
2540N/A * ssl_var_lookup could be rewritten to be MUCH faster
2453N/A * CRL callback should be pluggable
2453N/A * session cache store should be pluggable
2453N/A * init functions should return status code rather than ssl_die()
2453N/A * the shmcb code should just align its memory segment rather than
2453N/A jumping through all the "safe" memcpy and memset hoops
2453N/A * mod_proxy: Ability to run SSL over proxy gateway connections,
2453N/A encrypting (or reencrypting) at the proxy.
2453N/A * mod_cache: Handle ESI tags.
2453N/A * mod_cache: Resolve issue of how to cache page fragements (or perhaps
2453N/A will cache #include 'virtual' requests (but not #include 'file'
2453N/A requests). This was accomplished by making CACHE_IN a
2453N/A CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE
2453N/A filter. But now responses cannot be cached that include the
2453N/A effects of having been run through CONTENT_SET filters
838N/A (mod_deflate, mod_expires, etc). We could rerun all the
838N/A CONTENT_SET filters on the cached response, but this will not
2608N/A work in all cases. For example, mod_expires relies on installing
2608N/A the EXPIRATION filter during fixups. Contents served out of
2608N/A mod_cache (out of the quick_handler) bypass -all- the request
2608N/A line server hooks (Ryan really hated this. It is great for
838N/A performance, but bad because of the complications listed above).
838N/A * mod_mem_cache: Consider adding a RevalidateTimeout directive to
838N/A specify time at which local cached content is to be revalidated
342N/A (ie, underlying file stat'ed to see if it has changed).
838N/A jerenkrantz says: Too slow. Get regexs away from speedy caches by
2608N/A default. Introduce a new CacheEnableRegex if you want.
2608N/A status (num of entries, cache object properties, etc.).
926N/A mod_status could be extended to query optional hooks defined
838N/A by modules for the purpose of reporting module status.
838N/A mod_cache (et. al.) could define optional hooks that are called
838N/A to collect status. Status should be queryable by
838N/A jerenkrantz says: Yawn. Who cares.
2453N/A * MaxRequestsPerChild measures connections, not requests.
2453N/A Until someone has a better way, we'll probably just rename it
2453N/A * Regex containers don't work in an intutive way
2453N/A Status: No one has come up with an efficient way to fix this
2453N/A behavior. Dean has suggested getting rid of regex containers
2453N/A OtherBill suggests: We at least seem to agree on eliminating
926N/A the <Container ~ foo> forms, and using only
615N/A <ContainerMatch foo> semantics.
615N/A needed. Apache 1.3 just never stashed "multipart" into
615N/A r->content_type. We should probably follow suit since the
926N/A byterange stuff doesn't want the rest of the code to see the
615N/A multipart content-type; the other code should still think it is
615N/A dealing with the <orig_ct> stuff.
838N/A Status: Greg volunteers to investigate (esp. since he was most
111N/A likely the one to break it :-)
111N/A Experimental modules should eventually be be promoted to fully supported
111N/A status or removed from the repository entirely (ie, the
111N/A 'experiment' failed). This section tracks what needs to happen to
111N/A get the modules promoted to fully supported status.