278N/AAPACHE 2.5 STATUS: -*-text-*-
278N/ALast modified at [$Date$]
278N/AThe current version of this file can be found at:
278N/ADocumentation status is maintained separately and can be found at:
278N/AConsult the following STATUS files for information on related projects:
278N/APatches considered for backport are noted in their branches' STATUS:
278N/A 2.5.0 : In Development.
278N/AContributors looking for a mission:
278N/A * Just do an egrep on "TODO" or "XXX" in the source.
278N/A * Review the "PatchAvailable" bugs in the bug database:
278N/A After testing, you can append a comment saying "Reviewed and tested".
278N/A * Open bugs in the bug database.
278N/A * See also the STATUS file in the docs/ directory, which lists documentation-specific TODO items.
278N/A OLD ISSUES THAT WERE THOUGHT TO BE SHOWSTOPPERS FOR 2.4 BUT OBVIOUSLY WEREN'T:
278N/A * Handling of non-trailing / config by non-default handler is broken
278N/A jerenkrantz asks: Why should this block a release?
278N/A wsanchez agrees: this may be a change in behavior, but isn't
278N/A clearly wrong, and even if so, it doesn't seem like a
278N/A * the edge connection filter cannot be removed
278N/A jerenkrantz asks: Why should this block a release?
278N/A stas replies: because it requires a rewrite of the filters stack
278N/A implementation (you have suggested that) and once 2.2 is
278N/A released you can't do that anymore.
278N/A pgollucci: this affects mod_perl I'm pretty sure.
278N/A * Name the Server (version 2.4 or 3.0, depending on the final call)
278N/A Recent discussion indicates we should designate a (short name).
278N/A This is not yet a [Vote] - Your nominations please:
278N/A * Apache HTTP Server (httpd)
278N/A +1: sctemme (why mess with it?), pgollucci
278N/ARELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
278N/A * Clean up all the kruft and *extremely* outdated stuff below...
278N/A * Patches submitted to the bug database:
278N/A * Filter stacks and subrequests, redirects and fast redirects.
278N/A There's at least one PR that suffers from the current unclean behaviour
278N/A (which lets the server send garbage): PR 17629
278N/A nd says: Every subrequest should get its own filter stack with the
278N/A subreq_core filter as bottom-most. That filter does two things:
278N/A - redirect the data stream to the upper request's (rr->main)
278N/A filter chain directly after the subrequest's starting
278N/A Once we have a clean solution, we can try to optimize
278N/A it, so that the server won't be slow down too much.
278N/A Closed PRs: 15852, 15857, 15859, 15861, 15864, 15869, 15870, 16120,
278N/A 16125, 16135, 16136, 16137, 16138, 16139, 16140, 16518,
278N/A Open PRs: 15865, 15866, 15868, 16126, 16133, 16142, 16521, 42978
278N/A jerenkrantz says: need to decide how many we need to backport
and/or 278N/A if these rise to showstopper status.
278N/A wrowe suggests: it would be nice to see "MUST"
v.s. "SHOULD"
v.s. "MAY"
278N/A out of this list, without reviewing them individually.
278N/A * pipes deadlock on all platforms with limited pipe buffers (
e.g. both
278N/A Linux and Win32, as opposed to only Win32 on 1.3). The right solution
278N/A is either GStein's proposal for a "CGI Brigade", or OtherBill's proposal
278N/A for "Poll Buckets" for "Polling Filter Chains". Or maybe both :-)
278N/A * All handlers should always send content down even if r->header_only
278N/A is set. If not, it means that the HEAD requests don't generate the
278N/A same headers as a GET which is wrong.
278N/A * exec cmd and suexec arg-passing enhancements
278N/A Status: Patches proposed
278N/A Message-ID: <20020526041748.A29148@prodigy.Redbrick.DCU.IE>
278N/A * The 2.0.36 worker MPM graceless shutdown changes work but are
278N/A a bit clunky on some platforms; eg, on Linux, the loop to
278N/A join each worker thread seems to hang, and the parent ends up
278N/A killing off the child with SIGKILL. But at least it shuts down.
278N/A chrisd: Has this been fixed by the changes for PR 38737?
278N/A * We do not properly substitute the prefix-variables in the configuration
278N/A scripts or generated-configs. (
i.e. if sysconfdir is etc,
278N/A * If any request gets through ap_process_request_internal() and is
278N/A scheduled to be served by the core handler, without a flag that this
278N/A end of the ap_process_request_internal() processing so sub_req-esters
278N/A know this request cannot be run. This provides authors of older
278N/A modules better compatibility, while still improving the security and
278N/A Status: still need to decide where this goes, OtherBill comments...
278N/A Message-ID: <065701c14526$495203b0$96c0b0d0@roweclan.net>
278N/A [Deleted comments regarding the ap_run_handler phase, as irrelevant
278N/A as BillS points out that "common case will be caught in
278N/A and the issue is detecting this -before- we try to run the req.]
278N/A gregames says: can this happen somehow without a broken module
278N/A being involved? If not, why waste cycles trying to defend against
278N/A potential broken modules? It seems futile.
278N/A wrowe counters: no, it shouldn't happen unless the module is broken.
278N/A But the right answer is to fail the request up-front in
dir/file 278N/A walk if the path was entirely invalid; and we can't do that either
278N/A UNTIL 2.1 or we break modules that haven't hooked map_to_storage.
278N/A * Can a static httpd be built reliably?
278N/A Message-ID: <20020207142751.T31582@clove.org>
278N/A * Usage of APR_BRIGADE_NORMALIZE in core_input_filter should be
278N/A <Pine.LNX.4.33.0201202232430.318-100000@deepthought.cs.virginia.edu>
278N/A Jeff wonders if we still care about this. It is no longer an
278N/A API issue but simply an extra trip through the brigade.
278N/A * Try to get libtool inter-library dependency code working on AIX.
278N/A Message-ID: <cm3n10lx555.fsf@rdu163-40-092.nc.rr.com>
278N/A Justin says: If we get it working on AIX, we can enable this
278N/A on all platforms and clean up our build system somewhat.
278N/A Jeff says: I thought I tested a patch for you sometime in
278N/A January that you were going to commit within a few days.
278N/A * Handling of %2f in URIs. Currently both 1.3 and 2.0
278N/A completely disallow %2f in the request URI path (see
278N/A ap_unescape_url() in
util.c). It's permitted and passed
278N/A through in the query string, however. Roy says the
278N/A original reason for disallowing it, from five years ago,
278N/A was to protect CGI scripts that applied PATH_INFO to
278N/A a filesystem location and which might be tricked by
278N/A ..%2f..%2f(...). We *should* allow path-info of the
278N/A Since we've revamped a lot of our processing of path
278N/A segments, it would be nice to allow this, or at least
278N/A allow it conditionally with a directive.
278N/A OtherBill adds that %2f as the SECOND character of a multibyte
278N/A sequence causes the request to fail! This happens notably in
278N/A * There is increasing demand from module writers for an API
278N/A that will allow them to control the server à la apachectl.
278N/A Reasons include sole-function servers that need to die if
278N/A an external dependency (
e.g., a database) fails, et cetera.
278N/A Perhaps something in the (ever more abused) scoreboard?
278N/A On the other hand, we already have a pipe that goes between parent
278N/A and child for graceful shutdown events, along with an API that
278N/A can be used to send a message down that pipe. In threaded MPMs,
278N/A it is easy enough to make that one pipe be used for graceful
278N/A and graceless events, and it is also easy to open that pipe
278N/A to both parent and child for writing. Then we just need to
278N/A figure out how to do graceless on non-threaded MPMs.
278N/A * Allow the DocumentRoot directive within <Location > scopes? This
278N/A and in-your-face.) DocumentRoot unset would be accepted [and would
278N/A not permit content to be served, only virtual resources such as
278N/A server-info or server-status.
278N/A This proposed change would _not_ depricate Alias.
278N/A striker: See the thread starting with Message-ID:
278N/A JLEGKKNELMHCJPNMOKHOGEEJFBAA.striker@apache.org.
278N/A * Win32: Rotatelogs sometimes is not terminated when Apache
278N/A goes down hard. FirstBill was looking at possibly tracking the
278N/A child's-child processes in the parent process.
278N/A stoddard: Shared scoreboard might offer a good way for the parent
278N/A to keep track of 'other child' processes and whack them if the child
278N/A Other thoughts on walking the process chain using the NT kernel
278N/A have also been proposed on APR.
278N/A * Eliminate unnecessary creation of pipes in mod_cgid
278N/A * Platforms that do not support fork (primarily Win32 and AS/400)
278N/A Architect start-up code that avoids initializing all the modules
278N/A in the parent process on platforms that do not support fork.
278N/A * There are still a number of places in the code where we are
278N/A losing error status (
i.e. throwing away the error returned by a
278N/A system call and replacing it with a generic error code)
278N/A * Mass vhosting version of suEXEC.
278N/A the dbmmanage employs the first-matched dbm format. This is not
278N/A necessarily the library that Apache was built with. Aught to
278N/A rewrite dbmmanage upon installation to bin/ with the proper library
278N/A for predictable mod_auth_dbm administration.
278N/A Questions; htdbm exists, time to kill dbmmanage, or does it remain
278N/A useful as a perl dbm management example? If we keep it,
278N/A do we address the issue above?
278N/A Some additional items remaining:
278N/A - case_preserved_filename stuff
278N/A (use the new canonical name stuff?)
278N/A - find a new home for ap_text(_header)
278N/A - is it possible to remove the DAV: namespace stuff from util_xml?
278N/A * ap_core_translate() and its use by mod_mmap_static and mod_file_cache
278N/A are a bit wonky. The function should probably be exposed as a utility
278N/A function (such as ap_translate_url2fs() or ap_validate_fs_url() or
278N/A something). Another approach would be a new hook phase after
278N/A "translate" which would allow the module to munge what the
278N/A translation has decided to do.
278N/A Status: Greg +1 (volunteers)
278N/A calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and
278N/A ap_sort_hooks() [to reduce the logic in main()]
278N/A * read the config tree just once, and process N times (as necessary)
278N/A * (possibly) use UUIDs in mod_unique_id
and/or mod_usertrack
278N/A * (possibly) port the bug fix for PR 6942 (segv when LoadModule is put
278N/A into a VirtualHost container) to 2.0.
278N/A * callers of ap_run_create_request() should check the return value
278N/A for failure (Doug volunteers)
278N/A * Fix the worker MPM to use POD to kill child processes instead
278N/A of ap_os_killpg, regardless of how they should die.
278N/A chrisd: Is this done, by any chance? See r92598 and r93358.
278N/A * Scoreboard structures could be changed in the future such that
278N/A proper alignment is not maintained, leading to segfaults on
278N/A some systems. Cliff posted a patch to deal with this issue but
278N/A later recanted. See this message to dev@apr.apache.org:
278N/A <Pine.LNX.4.44.0203011354090.16457-200000@deepthought.cs.virginia.edu>
278N/A * APXS either needs to be fixed completely for use when apr is out of tree,
278N/A or it should drop query mode altogether, and we just grow an
278N/A httpd-config or similar arrangement.
278N/A To quote a discussion in STATUS earlier:
278N/A thommay: this doesn't fix all the problems with apxs and out of
278N/A query cases; but I'm beginning to think that in these cases
278N/A the app should be querying ap{r,u}-config directly
278N/A deprecate -q: add htpd-config: gstein, pquerna, minfrin, pgollucci
278N/ATODO ISSUES REMAINING IN MOD_SSL:
278N/A * Do we need SSL_set_read_ahead()?
278N/A * SSLRequire directive (parsing of) leaks memory
278N/A * Diffie-Hellman-Parameters for temporary keys are hardcoded in
278N/A "it is suggested that keys be changed daily or every 500
278N/A transactions, and more often if possible."
278N/A * ssl_var_lookup could be rewritten to be MUCH faster
278N/A * CRL callback should be pluggable
278N/A * init functions should return status code rather than ssl_die()
278N/A to also decrypt proxy keys
278N/A * mod_proxy: Ability to run SSL over proxy gateway connections,
278N/A encrypting (or reencrypting) at the proxy.
278N/A * mod_cache: Handle ESI tags.
278N/A * mod_cache: Resolve issue of how to cache page fragments (or perhaps
278N/A will cache #include 'virtual' requests (but not #include 'file'
278N/A requests). This was accomplished by making CACHE_IN a
278N/A CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE
278N/A filter. But now responses cannot be cached that include the
278N/A effects of having been run through CONTENT_SET filters
278N/A (mod_deflate, mod_expires, etc). We could rerun all the
278N/A CONTENT_SET filters on the cached response, but this will not
278N/A work in all cases. For example, mod_expires relies on installing
278N/A the EXPIRATION filter during fixups. Contents served out of
278N/A mod_cache (out of the quick_handler) bypass -all- the request
278N/A line server hooks (Ryan really hated this. It is great for
278N/A performance, but bad because of the complications listed above).
278N/A * mod_mem_cache: Consider adding a RevalidateTimeout directive to
278N/A specify time at which local cached content is to be revalidated
278N/A (ie, underlying file stat'ed to see if it has changed).
278N/A status (num of entries, cache object properties, etc.).
278N/A mod_status could be extended to query optional hooks defined
278N/A by modules for the purpose of reporting module status.
278N/A mod_cache (et. al.) could define optional hooks that are called
278N/A to collect status. Status should be queryable by
278N/A jerenkrantz says: Yawn. Who cares.
278N/A * Regex containers don't work in an intutive way
278N/A Status: No one has come up with an efficient way to fix this
278N/A behavior. Dean has suggested getting rid of regex containers
278N/A OtherBill suggests: We at least seem to agree on eliminating
278N/A the <Container ~ foo> forms, and using only
278N/A <ContainerMatch foo> semantics.
278N/A needed. Apache 1.3 just never stashed "multipart" into
278N/A r->content_type. We should probably follow suit since the
278N/A byterange stuff doesn't want the rest of the code to see the
278N/A multipart content-type; the other code should still think it is
278N/A dealing with the <orig_ct> stuff.
278N/A Status: Greg volunteers to investigate (esp. since he was most
278N/A likely the one to break it :-)
278N/A Experimental modules should eventually be be promoted to fully supported
278N/A status or removed from the repository entirely (ie, the
278N/A 'experiment' failed). This section tracks what needs to happen to
278N/A get the modules promoted to fully supported status.