httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Jaillet" <>
Subject Re: [STATUS] (httpd-trunk) Wed Aug 2 23:48:55 2006
Date Thu, 03 Aug 2006 05:51:13 GMT
In the section :

I think that the first link should target :

(the difference is product=Apache+httpd-2 instead of

The link in the post gives no result, whereas this one hits 120.

Christophe Jaillet

"Rodent of Unusual Size" <> a écrit dans le message de
> APACHE 2.3 STATUS:                                              -*-text-*-
> Last modified at [$Date: 2006-05-31 15:34:37 -0400 (Wed, 31 May 2006) $]
> The current version of this file can be found at:
>   *
> Documentation status is maintained seperately and can be found at:
>   * docs/STATUS in this source tree, or
>   *
> Consult the following STATUS files for information on related projects:
>   *
>   *
> Patches considered for backport are noted in their branches' STATUS:
>   *
>   *
>   *
> Release history:
>     [NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
>           while x.{even}.z versions are Stable/GA releases.]
>     2.3.0   : in development
> Contributors looking for a mission:
>     * Just do an egrep on "TODO" or "XXX" in the source.
>     * Review the bug database at:
>     * Review the "PatchAvailable" bugs in the bug database:
>       After testing, you can append a comment saying "Reviewed and
>     * Open bugs in the bug database.
>     * Handling of non-trailing / config by non-default handler is broken
>       jerenkrantz asks: Why should this block a release?
>       wsanchez agrees: this may be a change in behavior, but isn't
>         clearly wrong, and even if so, it doesn't seem like a
>         showstopper.
>     * the edge connection filter cannot be removed
>       jerenkrantz asks: Why should this block a release?
>       stas replies: because it requires a rewrite of the filters stack
>             implementation (you have suggested that) and once 2.2 is
>             released you can't do that anymore.
>     * 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: <3C58232C.FE91F19F@Golux.Com>
>       Self-destruct: Ken, Martin, Lars
>       Not self-destruct: BrianP, Ian, Cliff, BillS
>       Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
>       /* The below was a concept on *how* to handle the problem */
>       Have 2 parents: +1: jim
>                       -1: Justin, wrowe, rederpj, nd
>                       +0: Lars, 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, wrowe, nd
>       +0:   BrianP, Aaron (mutex contention is looking better with the
>             latest code, let's continue tuning and testing), rederpj, jim
>       -0:   Lars
>       pquerna: Do we want to change this for 2.2?
>     * Patches submitted to the bug database:
>     * Filter stacks and subrequests, redirects and fast redirects.
>       There's at least one PR that suffers from the current unclean
>       (which lets the server send garbage): PR 17629
>       nd says: Every subrequest should get its own filter stack with the
>                subreq_core filter as bottom-most. That filter does two
>                  - swallow EOS buckets
>                  - redirect the data stream to the upper request's
>                    filter chain directly after the subrequest's starting
>                    point.
>                Once we have a clean solution, we can try to optimize
>                it, so that the server won't be slow down too much.
>     * RFC 2616 violations.
>       Closed PRs: 15857.
>       Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
>                 15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
>                 16138, 16139, 16140, 16142, 16518, 16520, 16521,
>       jerenkrantz says: need to decide how many we need to backport and/or
>                         if these rise to showstopper status.
>       wrowe suggests: it would be nice to see "MUST" v.s. "SHOULD" v.s.
>                       out of this list, without reviewing them
>     * 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.
>       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.
>         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
>       is either GStein's proposal for a "CGI Brigade", or OtherBill's
>       for "Poll Buckets" for "Polling Filter Chains".  Or maybe 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.
>     * exec cmd and suexec arg-passing enhancements
>       Status: Patches proposed
>       Message-ID: <20020526041748.A29148@prodigy.Redbrick.DCU.IE>
>       (see the "proc.patch" and "suexec-shell.patch" links in this
>     * 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.
>         chrisd: Has this been fixed by the changes for PR 38737?
>     * --enable-mods-shared="foo1 foo2" is busted on Darwin.  Pier
>         posted a patch (Message-ID: <>).
>     * We do not properly substitute the prefix-variables in the
>       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
>       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
>         Message-ID: <065701c14526$495203b0$>
>         [Deleted comments regarding the ap_run_handler phase, as
>             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
> gregames says: can this happen somehow without a broken module
>             being involved?  If not, why waste cycles trying to defend
>             potential broken modules?  It seems futile.
>         wrowe counters: no, it shouldn't happen unless the module is
>             But the right answer is to fail the request up-front in
>             walk if the path was entirely invalid; and we can't do that
>             UNTIL 2.1 or we break modules that haven't hooked
>     * 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.
>     * Can a static httpd be built reliably?
>         Message-ID: <>
>     * Usage of APR_BRIGADE_NORMALIZE in core_input_filter should be
>       removed if possible.
>         Message-ID:
>         Jeff wonders if we still care about this.  It is no longer an
>         API issue but simply an extra trip through the brigade.
>     * 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 dev@apr:
>         Message-ID: <>
>     * Try to get libtool inter-library dependency code working on AIX.
>         Message-ID: <>
>       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 ''.
>       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.
>     * 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: Works with FreeBSD 5.3. Does not work in previous
>                 This has also been reported on Cygwin.
>     * 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
>              and child for graceful shutdown events, along with an API
>              can be used to send a message down that pipe.  In threaded
>              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.
>     * Allow the DocumentRoot directive within <Location > scopes?  This
>       allows the beloved (crusty) Alias /foo/ /somepath/foo/ followed
>       by a <Directory /somepath/foo> to become simply
>       <Location /foo/> DocumentRoot /somefile/foo (IMHO a bit more legible
>       and in-your-face.)  DocumentRoot unset would be accepted [and would
>       not permit content to be served, only virtual resources such as
>       server-info or server-status.
>       This proposed change would _not_ depricate Alias.
>         striker: See the thread starting with Message-ID:
>     * 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
>         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.
>     * Platforms that do not support fork (primarily Win32 and AS/400)
>       Architect start-up code that avoids initializing all the modules
>       in the parent process on platforms that do not support fork.
>     * 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)
>       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
>                    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
>       are a bit wonky.  The function should probably be exposed as a
>       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)
>     * (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)
>     * Fix the worker MPM to use POD to kill child processes instead
>       of ap_os_killpg, regardless of how they should die.
>         chrisd: Is this done, by any chance?  See r92598 and r93358.
>     * 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
>       Message-ID: <Pine.LNX.4.44.0203011354090.16457-200000@deepthought
>         >
>     * APXS either needs to be fixed completely for use when apr is out of
>       or it should drop query mode altogether, and we just grow an
>       httpd-config or similar arrangement.
>       To quote a discussion in STATUS earlier:
>           thommay: this doesn't fix all the problems with apxs and out of
>                    tree apr/apr-util, but it's a good start. There's still
>                    query cases; but I'm beginning to think that in these
>                    the app should be querying ap{r,u}-config directly
>           gstein: agreed. apxs should deprecate the -q flag
>           pquerna: I vote for a httpd-config, and to deprecate the -q
>           minfrin: +1 for httpd-config, and to deprecate -q.
>     * 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
>     * mod_proxy: Ability to run SSL over proxy gateway connections,
>       encrypting (or reencrypting) at the proxy.
>     * mod_cache: Handle ESI tags.
>     * mod_cache: Resolve issue of how to cache page fragements (or perhaps
>       -if- we want to cache page fragements). Today,
>       will cache #include 'virtual' requests (but not #include 'file'
>       requests). This was accomplished by making CACHE_IN a
>       CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE
>       filter.  But now responses cannot be cached that include the
>       effects of having been run through CONTENT_SET filters
>       (mod_deflate, mod_expires, etc).  We could rerun all the
>       CONTENT_SET filters on the cached response, but this will not
>       work in all cases. For example, mod_expires relies on installing
>       the EXPIRATION filter during fixups. Contents served out of
>       mod_cache (out of the quick_handler) bypass -all- the request
>       line server hooks (Ryan really hated this. It is great for
>       performance, but bad because of the complications listed above).
>     mod_cache/mod_mem_cache/mod_disk_cache:
>     * mod_mem_cache: Consider adding a RevalidateTimeout directive to
>       specify time at which local cached content is to be revalidated
>       (ie, underlying file stat'ed to see if it has changed).
>     * mod_cache: CacheEnable/CacheDisable should accept regular
>       jerenkrantz says: Too slow.  Get regexs away from speedy caches by
>                         default.  Introduce a new CacheEnableRegex if you
>     * 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?
>       jerenkrantz says: Yawn.  Who cares.
>     * 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.
>     * 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 :-)
>     Experimental modules should eventually be be promoted to fully
>     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.

View raw message