STATUS revision f326ab45ec25cf93687a273c9db07cb9a5108c16
f743002678eb67b99bbc29fee116b65d9530fec0wroweAPACHE 2.1 STATUS: -*-text-*-
80833bb9a1bf25dcf19e814438a4b311d2e1f4cffuankgLast modified at [$Date: 2003/08/31 16:14:38 $]
cb666b29f81df1d11d65002250153353568021fccovenerRelease [NOTE that only Alpha/Beta releases occur in 2.1 development]:
cb666b29f81df1d11d65002250153353568021fccovener 2.1.0 : in development
f58fcd9d79be417ef351cac4e4c0ab264c5521e0trawickPlease consult the following STATUS files for information
f58fcd9d79be417ef351cac4e4c0ab264c5521e0trawickon related projects:
45dffe6c346dd73571ccaead10295fc7d53b59a6covenerContributors looking for a mission:
75a230a728338d84dcfe81edd375352f34de22d0covener * just do an egrep on "TODO" or "XXX" and see what's there
3694b0116c5729804ed6a5ce119bd8efda116c7fcovenerCURRENT RELEASE NOTES:
3694b0116c5729804ed6a5ce119bd8efda116c7fcovenerRELEASE SHOWSTOPPERS:
1f50dc34ae069adeed20b2986e5ffdefa5c410e0covener * Handling of non-trailing / config by non-default handler is broken
1f50dc34ae069adeed20b2986e5ffdefa5c410e0covener http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2
63a5ea80bddcc84a462e40f402b4f330e0e05411covener * the edge connection filter cannot be removed
63a5ea80bddcc84a462e40f402b4f330e0e05411covener http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2
986f3ea2c314d4d4b3b937149853a0f23f6119aaminfrinCURRENT VOTES:
986f3ea2c314d4d4b3b937149853a0f23f6119aaminfrin * Promote mod_cache from experimental to non-experimental
f502dd154eaf60ccf6a993e83c490d52cd0a385eminfrin status (keep issues noted below in EXPERIMENTAL MODULES as
f502dd154eaf60ccf6a993e83c490d52cd0a385eminfrin items to be addressed as a supported module).
f502dd154eaf60ccf6a993e83c490d52cd0a385eminfrin +1: jim, bnicholes
65a4e663b82f8bce28ac22ab2edfd7502de36998sf -0: jerenkrantz
65a4e663b82f8bce28ac22ab2edfd7502de36998sf -1: stoddard
65a4e663b82f8bce28ac22ab2edfd7502de36998sf There are a couple of problems that need to be resolved
65a4e663b82f8bce28ac22ab2edfd7502de36998sf before this module is moved out of experimental.
c7de1955eb0eaeabf7042902476397692672d549sf 1) We need to at least review and comment on the RFC violations
cc5a4a08dc9783fcbc52ce86f11e01c281a43810minfrin 2) Resolve issue of how to cache page fragements (or perhaps -if- we
cc5a4a08dc9783fcbc52ce86f11e01c281a43810minfrin want to cache page fragements). Today, mod_cache/mod_mem_cache
cc5a4a08dc9783fcbc52ce86f11e01c281a43810minfrin will cache #include 'virtual' requests (but not #include 'file'
cc5a4a08dc9783fcbc52ce86f11e01c281a43810minfrin requests). This was accomplished by making CACHE_IN a
a77a7d850e4496179e1e0f45d5152865c899d421covener CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE
a77a7d850e4496179e1e0f45d5152865c899d421covener filter. But now responses cannot be cached that include the
92108a6c4fd7ca6e9acc94d2485920436763e491sf effects of having been run through CONTENT_SET filters
df6d5653669f1514b4449aaba99cb950c0013e5fcovener (mod_deflate, mod_expires, etc). We could rerun all the
df6d5653669f1514b4449aaba99cb950c0013e5fcovener CONTENT_SET filters on the cached response, but this will not
df6d5653669f1514b4449aaba99cb950c0013e5fcovener work in all cases. For example, mod_expires relies on installing
509622419be000045d461ef38fb97df778fdf81djailletc the EXPIRATION filter during fixups. Contents served out of
509622419be000045d461ef38fb97df778fdf81djailletc mod_cache (out of the quick_handler) bypass -all- the request
509622419be000045d461ef38fb97df778fdf81djailletc line server hooks (Ryan really hated this. It is great for
509622419be000045d461ef38fb97df778fdf81djailletc performance, but bad because of the complications listed above).
1de839c61281d58dc75715c1ae06b4b00764c4efjorton jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla
2e1a0fb12bdf1c20064ffe900a8f44979ec946fcminfrin for mod_cache (see 'RFC 2616 violations' below). I think
2e1a0fb12bdf1c20064ffe900a8f44979ec946fcminfrin fixing them is a pre-requisite before it isn't experimental.
441d366a564bc6faa7c1eaffbacf8c4f37862199minfrin a) httpd-std.conf should be tailored by install (from src or
441d366a564bc6faa7c1eaffbacf8c4f37862199minfrin binbuild) even if user has existing httpd.conf
441d366a564bc6faa7c1eaffbacf8c4f37862199minfrin +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd,
0b9de55d178312ec929dbe417dd61199b269991djailletc wrowe - prefer httpd.default.conf to avoid ambiguity with cvs
0b9de55d178312ec929dbe417dd61199b269991djailletc b) tailored httpd-std.conf should be copied by install to
74e7f6c55fd67b10cb400b3f6d1dc718a303d944minfrin -0: striker
74e7f6c55fd67b10cb400b3f6d1dc718a303d944minfrin c) tailored httpd-std.conf should be installed to
9e0d78337da0ce66247fc3254b9d5be262cbcea8minfrin +1: slive, trawick, Ken, nd (prefer the latter), erikabele
9e0d78337da0ce66247fc3254b9d5be262cbcea8minfrin d) Installing a set of default config files when upgrading a server
2ae6440d9c0beacb1b2a9726d80b755a8a4a851bjailletc doesn't make ANY sense at all.
2ae6440d9c0beacb1b2a9726d80b755a8a4a851bjailletc +1: ianh - medium/big sites don't use 'standard config' anyway, as it
2ae6440d9c0beacb1b2a9726d80b755a8a4a851bjailletc usually needs major customizations
2ae6440d9c0beacb1b2a9726d80b755a8a4a851bjailletc -1: Ken, wrowe, jwoolley, jim, nd, erikabele
2f073ef2a21b1725addef84f318a2b11541e912aminfrin wrowe - diff is wonderful when comparing old/new default configs,
2f073ef2a21b1725addef84f318a2b11541e912aminfrin even for customized sites that ianh mentions
2f073ef2a21b1725addef84f318a2b11541e912aminfrin jim - ... assuming that the default configs have been updated
2f073ef2a21b1725addef84f318a2b11541e912aminfrin with the required inline docs to explain the
a511a29faf2ff7ead3b67680154a624effb31aafminfrin * If the parent process dies, should the remaining child processes
a511a29faf2ff7ead3b67680154a624effb31aafminfrin "gracefully" self-terminate. Or maybe we should make it a runtime
a511a29faf2ff7ead3b67680154a624effb31aafminfrin option, or have a concept of 2 parent processes (one being a
a7584fbbf39ae6a78586ed038d80c31b14ce5461minfrin "hot spare").
a7584fbbf39ae6a78586ed038d80c31b14ce5461minfrin See: Message-ID: <3C58232C.FE91F19F@Golux.Com>
a7584fbbf39ae6a78586ed038d80c31b14ce5461minfrin Self-destruct: Ken, Martin, Lars
9ea14ade0d235bec11e6c221b888a6630a0be849covener Not self-destruct: BrianP, Ian, Cliff, BillS
9ea14ade0d235bec11e6c221b888a6630a0be849covener Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
4860eae0821bbdf3e0da78be7b4057ebed5d86e4minfrin /* The below was a concept on *how* to handle the problem */
4860eae0821bbdf3e0da78be7b4057ebed5d86e4minfrin Have 2 parents: +1: jim
4860eae0821bbdf3e0da78be7b4057ebed5d86e4minfrin -1: Justin, wrowe, rederpj, nd
5b6a4b0e8d6d52394b68b51e0fa439d0eee16e37minfrin +0: Lars, Martin (while standing by, could it do
5b6a4b0e8d6d52394b68b51e0fa439d0eee16e37minfrin something useful?)
5b6a4b0e8d6d52394b68b51e0fa439d0eee16e37minfrin * Make the worker MPM the default MPM for threaded Unix boxes.
2344a0c1817b88b6df61fc4ed0c6af66bb93ee6bjim +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
2344a0c1817b88b6df61fc4ed0c6af66bb93ee6bjim +0: BrianP, Aaron (mutex contention is looking better with the
2344a0c1817b88b6df61fc4ed0c6af66bb93ee6bjim latest code, let's continue tuning and testing), rederpj, jim
63921358ef93fcb41bc71d9894221ba3d7fbb87bminfrinRELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
63921358ef93fcb41bc71d9894221ba3d7fbb87bminfrin * Filter stacks and subrequests, redirects and fast redirects.
bbb08feeeef547b0908b16df6cbbb65da656b86fminfrin There's at least one PR that suffers from the current unclean behaviour
bbb08feeeef547b0908b16df6cbbb65da656b86fminfrin (which lets the server send garbage): PR 17629
bbb08feeeef547b0908b16df6cbbb65da656b86fminfrin nd says: Every subrequest should get its own filter stack with the
bbb08feeeef547b0908b16df6cbbb65da656b86fminfrin subreq_core filter as bottom-most. That filter does two things:
eee20257a5ee9228f4aecdf3d3ca68fd0683ff07minfrin - swallow EOS buckets
eee20257a5ee9228f4aecdf3d3ca68fd0683ff07minfrin - redirect the data stream to the upper request's (rr->main)
eee20257a5ee9228f4aecdf3d3ca68fd0683ff07minfrin filter chain directly after the subrequest's starting
eee20257a5ee9228f4aecdf3d3ca68fd0683ff07minfrin Once we have a clean solution, we can try to optimize
eee20257a5ee9228f4aecdf3d3ca68fd0683ff07minfrin it, so that the server won't be slow down too much.
decb536ebd4b7b94c7450c2e1daa491943135abdminfrin * RFC 2616 violations.
decb536ebd4b7b94c7450c2e1daa491943135abdminfrin Closed PRs: 15857.
decb536ebd4b7b94c7450c2e1daa491943135abdminfrin Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
decb536ebd4b7b94c7450c2e1daa491943135abdminfrin 15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
2d2c5cedd0559093c6e88bd92702e369ef949336minfrin 16138, 16139, 16140, 16142, 16518, 16520, 16521,
2d2c5cedd0559093c6e88bd92702e369ef949336minfrin jerenkrantz says: need to decide how many we need to backport and/or
2d2c5cedd0559093c6e88bd92702e369ef949336minfrin if these rise to showstopper status.
2d2c5cedd0559093c6e88bd92702e369ef949336minfrin wrowe suggests: it would be nice to see "MUST" v.s. "SHOULD" v.s. "MAY"
2d2c5cedd0559093c6e88bd92702e369ef949336minfrin out of this list, without reviewing them individually.
2b82678319a66fd9caad8827ca9b38d2412a5abdminfrin * There is a bug in how we sort some hooks, at least the pre-config
c0da461d68518e8f89f4070a709ba1e56381247cminfrin hook. The first time we call the hooks, they are in the correct
c0da461d68518e8f89f4070a709ba1e56381247cminfrin order, but the second time, we don't sort them correctly. Currently,
c0da461d68518e8f89f4070a709ba1e56381247cminfrin the modules/http/config.m4 file has been renamed to
797fb211307298a8a6984c0edc0d8972b35eeac1minfrin modules/http/config2.m4 to work around this problem, it should moved
797fb211307298a8a6984c0edc0d8972b35eeac1minfrin back when this is fixed.
797fb211307298a8a6984c0edc0d8972b35eeac1minfrin OtherBill offers that this is a SERIOUS problem. We do not sort
f27c90ecdefe634bd5f9c529d8658d3a3b441303minfrin correctly by the ordering arguments passed to the register hook
f27c90ecdefe634bd5f9c529d8658d3a3b441303minfrin functions. This was proven when I reordered the open_logs hook
f27c90ecdefe634bd5f9c529d8658d3a3b441303minfrin to attempt to open the error logs prior to the access logs. Possibly
80cabec6752622e0db5421af61502bfda95715eaminfrin the entire sorting code needs to be refactored.
80cabec6752622e0db5421af61502bfda95715eaminfrin * pipes deadlock on all platforms with limited pipe buffers (e.g. both
a2e1bbb77dd09c6a60f2dc18f831000e49add31eminfrin Linux and Win32, as opposed to only Win32 on 1.3). The right solution
a2e1bbb77dd09c6a60f2dc18f831000e49add31eminfrin is either GStein's proposal for a "CGI Brigade", or OtherBill's proposal
a2e1bbb77dd09c6a60f2dc18f831000e49add31eminfrin for "Poll Buckets" for "Polling Filter Chains". Or maybe both :-)
a2e1bbb77dd09c6a60f2dc18f831000e49add31eminfrin * All handlers should always send content down even if r->header_only
a2e1bbb77dd09c6a60f2dc18f831000e49add31eminfrin is set. If not, it means that the HEAD requests don't generate the
deec48c67d4786bc77112ffbf3a4e70b931097edminfrin same headers as a GET which is wrong.
deec48c67d4786bc77112ffbf3a4e70b931097edminfrin * HP/UX 10.20: compile breakage in APR. Looks like it should be easy
deec48c67d4786bc77112ffbf3a4e70b931097edminfrin to fix, probably just some extraneous #include's that are fouling
6d601599d3d65df0410eae6e573e75b2dbfb1fb4minfrin Jeff: See my reply and patch in the PR (and previous commit to
6d601599d3d65df0410eae6e573e75b2dbfb1fb4minfrin stop using "pipe" as a field name). If patch is committed, we
40d570cf1420f497bcac59045d4ce477f0b5d891minfrin should be okay. I'll wait to see if the user tests the patch.
40d570cf1420f497bcac59045d4ce477f0b5d891minfrin Update by Jeff 20020722: I got an account on HP 10.20. It looks
40d570cf1420f497bcac59045d4ce477f0b5d891minfrin like some of the APR thread detection is screwed up. If we find
edab53cc0be707fa71968a95c696b19f0e6c4736minfrin pthread.h but we can't compile the pthread test program we still
edab53cc0be707fa71968a95c696b19f0e6c4736minfrin think we can use threads. For that reason, the patch I posted
edab53cc0be707fa71968a95c696b19f0e6c4736minfrin to the PR won't work as-is since a failed compile of the test
806e9ba570ef48df4bfd8364e2f4d57381388a11minfrin program means nothing.
806e9ba570ef48df4bfd8364e2f4d57381388a11minfrin * exec cmd and suexec arg-passing enhancements
806e9ba570ef48df4bfd8364e2f4d57381388a11minfrin Status: Patches proposed
806e9ba570ef48df4bfd8364e2f4d57381388a11minfrin Message-ID: <20020526041748.A29148@prodigy.Redbrick.DCU.IE>
a4273e3e513ce8f5e1311c320cbd334cc382950eminfrin (see the "proc.patch" and "suexec-shell.patch" links in this message)
a4273e3e513ce8f5e1311c320cbd334cc382950eminfrin * The 2.0.36 worker MPM graceless shutdown changes work but are
d3e0a61e1bcc497f2efd7af41a5a9d77090ecc1cminfrin a bit clunky on some platforms; eg, on Linux, the loop to
a4273e3e513ce8f5e1311c320cbd334cc382950eminfrin join each worker thread seems to hang, and the parent ends up
d3e0a61e1bcc497f2efd7af41a5a9d77090ecc1cminfrin killing off the child with SIGKILL. But at least it shuts down.
1aac1c71105133d669960501bdf2274e63561054minfrin * --enable-mods-shared="foo1 foo2" is busted on Darwin. Pier
1aac1c71105133d669960501bdf2274e63561054minfrin posted a patch (Message-ID: <B8DBBE8D.575A%pier@betaversion.org>).
2c487ac43b583db869e743772a7a10b278aa2bcfminfrin * We do not properly substitute the prefix-variables in the configuration
2c487ac43b583db869e743772a7a10b278aa2bcfminfrin scripts or generated-configs. (i.e. if sysconfdir is etc,
2c487ac43b583db869e743772a7a10b278aa2bcfminfrin httpd-std.conf points to conf.)
2c487ac43b583db869e743772a7a10b278aa2bcfminfrin * If any request gets through ap_process_request_internal() and is
dbf5f584c62fe6030d81121fdddeb7588b78b867sf scheduled to be served by the core handler, without a flag that this
dbf5f584c62fe6030d81121fdddeb7588b78b867sf r->filename was tested by dir/file_walk, we need to 500 at the very
15320dc646e41d3eb38736978500349c4d66dc0dsf end of the ap_process_request_internal() processing so sub_req-esters
15320dc646e41d3eb38736978500349c4d66dc0dsf know this request cannot be run. This provides authors of older
691db92094897494d6c31326108da20088bc175etrawick modules better compatibility, while still improving the security and
691db92094897494d6c31326108da20088bc175etrawick robustness of 2.0.
92108a6c4fd7ca6e9acc94d2485920436763e491sf Status: still need to decide where this goes, OtherBill comments...
92108a6c4fd7ca6e9acc94d2485920436763e491sf Message-ID: <065701c14526$495203b0$96c0b0d0@roweclan.net>
684e0cfc200f66287a93bbd1708d1dd8a92a7eefcovener [Deleted comments regarding the ap_run_handler phase, as irrelevant
684e0cfc200f66287a93bbd1708d1dd8a92a7eefcovener as BillS points out that "common case will be caught in
684e0cfc200f66287a93bbd1708d1dd8a92a7eefcovener default_handler already (with the r->finfo.filetype == 0 check)"
5c43d2fb853f84497b5ece2d414ef9484aa87e5fsf and the issue is detecting this -before- we try to run the req.]
05a5a9c3e16f21566e1b61f4bd68025ce1b741ccjoes gregames says: can this happen somehow without a broken module
ef82e8fa164e0a1f8b813f7deb6b7ead96018c94niq being involved? If not, why waste cycles trying to defend against
26c5829347f6a355c00f1ba0301d575056b69536niq potential broken modules? It seems futile.
ef82e8fa164e0a1f8b813f7deb6b7ead96018c94niq wrowe counters: no, it shouldn't happen unless the module is broken.
ef82e8fa164e0a1f8b813f7deb6b7ead96018c94niq But the right answer is to fail the request up-front in dir/file
ef82e8fa164e0a1f8b813f7deb6b7ead96018c94niq walk if the path was entirely invalid; and we can't do that either
ef82e8fa164e0a1f8b813f7deb6b7ead96018c94niq UNTIL 2.1 or we break modules that haven't hooked map_to_storage.
ef82e8fa164e0a1f8b813f7deb6b7ead96018c94niq * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me
413ee814748f37be168ff12407fa6dba0ceeabe6trawick how the Perchild MPM should be re-written. It hasn't worked
c12917da693bae4028a1d5a5e8224bceed8c739dsf correctly since filters were added because it wasn't possible to
c12917da693bae4028a1d5a5e8224bceed8c739dsf get the content that had already been written and the socket at
eeb7898b9c087040d44550f8a6b1a257783c9f0ahumbedooh the same time. This mode lets us do that, so the MPM can be
eafcc0ebf263d0ba69855b6e10958c4c1a2361bdsf * Can a static httpd be built reliably?
eafcc0ebf263d0ba69855b6e10958c4c1a2361bdsf Message-ID: <20020207142751.T31582@clove.org>
eafcc0ebf263d0ba69855b6e10958c4c1a2361bdsf * [Ken] Test suite failures:
eafcc0ebf263d0ba69855b6e10958c4c1a2361bdsf o worker is also failing some of the 'cgi' subtests
d7ffd2da16d58b1a0de212e4d56f7aebb72bef26sf Justin says: "Worker should be fine and passes httpd-test here.
d7ffd2da16d58b1a0de212e4d56f7aebb72bef26sf I think it's a perl or a httpd-test problem."
4576c1a9ef54cd1e5555ee07d016a7f559f80338sf * Usage of APR_BRIGADE_NORMALIZE in core_input_filter should be
4576c1a9ef54cd1e5555ee07d016a7f559f80338sf removed if possible.
9811aed12bbc71783d2e544ccb5fecd193843eadsf Message-ID: <Pine.LNX.4.33.0201202232430.318-100000@deepthought.cs.virginia.edu>
9811aed12bbc71783d2e544ccb5fecd193843eadsf Jeff wonders if we still care about this. It is no longer an
9811aed12bbc71783d2e544ccb5fecd193843eadsf API issue but simply an extra trip through the brigade.
d58a822aff1dfda25384d3d009f88f1883c95436kbrand * The Add...Filter and Set...Filter directives do not allow the
d58a822aff1dfda25384d3d009f88f1883c95436kbrand administrator to order filters, beyond the order of filename (mime)
e02ff627c1e63137247e20493f6ef44b3bb1a095sf extensions. It isn't clear if Set...Filter(s) should be inserted
e02ff627c1e63137247e20493f6ef44b3bb1a095sf before or after the Add...Filter(s) which are ordered by sequence of
e02ff627c1e63137247e20493f6ef44b3bb1a095sf filename extensions. At minimum, some sort of +-[0-10] syntax seems
1366443dc565c33e7b449ae428bbfc4c86f33935drh like a nice solution. See ROADMAP.
88fac54d9d64f85bbdab5d7010816f4377f95bd7rjung * Get perchild to work on platforms other than Linux. This
88fac54d9d64f85bbdab5d7010816f4377f95bd7rjung will require a portable mechanism to pass data and file/socket
bd3f5647b96d378d9c75c954e3f13582af32c643sf descriptors between vhost child groups. An API was proposed
bd3f5647b96d378d9c75c954e3f13582af32c643sf on dev@apr:
bd3f5647b96d378d9c75c954e3f13582af32c643sf Message-ID: <20020111115006.K1529@clove.org>
bd3f5647b96d378d9c75c954e3f13582af32c643sf * Try to get libtool inter-library dependency code working on AIX.
2a7beea91d46beb41f043a84eaad060047ee04aafabien Message-ID: <cm3n10lx555.fsf@rdu163-40-092.nc.rr.com>
2a7beea91d46beb41f043a84eaad060047ee04aafabien Justin says: If we get it working on AIX, we can enable this
2a7beea91d46beb41f043a84eaad060047ee04aafabien on all platforms and clean up our build system
584a85dd4047e38d3ed3a29b6662fcc9d100ae4csf Jeff says: I thought I tested a patch for you sometime in
584a85dd4047e38d3ed3a29b6662fcc9d100ae4csf January that you were going to commit within a few
f21e9e3d0bfb7a507ecc5bc963f2159d693503d1sf * Handling of %2f in URIs. Currently both 1.3 and 2.0
f6b9c755a0b793e8a3a3aebd327ca20a86478117sf completely disallow %2f in the request URI path (see
f6b9c755a0b793e8a3a3aebd327ca20a86478117sf ap_unescape_url() in util.c). It's permitted and passed
f6b9c755a0b793e8a3a3aebd327ca20a86478117sf through in the query string, however. Roy says the
132ee6ac1c26d6e8953836316ba50734eefab47bsf original reason for disallowing it, from five years ago,
132ee6ac1c26d6e8953836316ba50734eefab47bsf was to protect CGI scripts that applied PATH_INFO to
132ee6ac1c26d6e8953836316ba50734eefab47bsf a filesystem location and which might be tricked by
fc1459657a1fde206a847f9028930725d715f8b4trawick ..%2f..%2f(...). We *should* allow path-info of the
fc1459657a1fde206a847f9028930725d715f8b4trawick form 'http://foo.com/index.cgi/path/to/path%2finfo'.
fc1459657a1fde206a847f9028930725d715f8b4trawick Since we've revamped a lot of our processing of path
85eacfc96a04547ef25aabbc06440039715084c2jorton segments, it would be nice to allow this, or at least
85eacfc96a04547ef25aabbc06440039715084c2jorton allow it conditionally with a directive.
68ba377fc3b124baa759662077c48077ebadb186minfrin OtherBill adds that %2f as the SECOND character of a multibyte
68ba377fc3b124baa759662077c48077ebadb186minfrin sequence causes the request to fail! This happens notably in
68ba377fc3b124baa759662077c48077ebadb186minfrin the ja-jis encoding.
d776b0a2d2889ce1d13494873368f34327a2e1bbtrawick * FreeBSD, threads, and worker MPM. All seems to work fine
d776b0a2d2889ce1d13494873368f34327a2e1bbtrawick if you only have one worker process with many threads. Add
f4ca9f6f002fece336168a16355434ca966f96a9trawick a second worker process and the accept lock seems to be
78f94f1d06c4e6828ce04d618221e0fcecb57849humbedooh lost. This might be an APR issue with how it deals with
78f94f1d06c4e6828ce04d618221e0fcecb57849humbedooh the child_init hook (i.e. the fcntl lock needs to be resynced).
78f94f1d06c4e6828ce04d618221e0fcecb57849humbedooh More examination and analysis is required.
536d2e7cd1fdec1255b8c3bdf41fdc714c506a54trawick Status: This has also been reported on Cygwin.
536d2e7cd1fdec1255b8c3bdf41fdc714c506a54trawick FreeBSD 4.7 was reputed to have 'fixed' threads. Not.
536d2e7cd1fdec1255b8c3bdf41fdc714c506a54trawick Message-ID: <3C2CC514.8EF3BED1@wapme-systems.de> (cygnus)
70caa242e6b90e0d6f0fabb56b8c5c2fb51717b3jorton Aaron says: I spent some time disecting this and have come to
985a4368b93c3e9171a57897ad9454c8dbf4cdf6jorton the conclusion that it is not a problem in the worker MPM
70caa242e6b90e0d6f0fabb56b8c5c2fb51717b3jorton (or at least, it is not isolated to a problem in worker).
70caa242e6b90e0d6f0fabb56b8c5c2fb51717b3jorton I'll list some of the problems I'm seeing in case someone
109e2a09790de3fb315d36d6232a14ab66c8eb0ahumbedooh else wants to pick up where I've left off:
109e2a09790de3fb315d36d6232a14ab66c8eb0ahumbedooh - Delivery of just about any signal to one of the child
109e2a09790de3fb315d36d6232a14ab66c8eb0ahumbedooh processes will send it into an infinite loop as well.
74e7a30182af5e68f14ccb8d57918b22b982db8bhumbedooh - Even though the parent is spinning out of control,
74e7a30182af5e68f14ccb8d57918b22b982db8bhumbedooh at first the child or children will appear to work
74e7a30182af5e68f14ccb8d57918b22b982db8bhumbedooh properly. At times it is possible to get it into a state,
10961a2f60207cb873d889bb28b1f0ef707a4311humbedooh however, where a request will hang until another concurrent
10961a2f60207cb873d889bb28b1f0ef707a4311humbedooh request "kicks" the first, at which point the second will
10961a2f60207cb873d889bb28b1f0ef707a4311humbedooh hang. My theory is that this has to do with the
0448378b899e8df0c060360f17c0af692adf17bchumbedooh pthread_cond_*() implementation in FreeBSD, but it's still
0448378b899e8df0c060360f17c0af692adf17bchumbedooh possible that it is in APR.
60a765cccbd3f3b5997b65b0034220c79f78369etrawick Justin adds: Oh, FreeBSD threads are implemented entirely with
60a765cccbd3f3b5997b65b0034220c79f78369etrawick select()/poll()/longjmp(). Welcome to the nightmare.
60a765cccbd3f3b5997b65b0034220c79f78369etrawick So, that means a ktrace output also has the thread
e7ca863b04ee2a7aea7738cadbf51ce5e6c5245dhumbedooh scheduling internals in it (since it is all the same to
e7ca863b04ee2a7aea7738cadbf51ce5e6c5245dhumbedooh the kernel). Which makes it hard to distinguish between
e7ca863b04ee2a7aea7738cadbf51ce5e6c5245dhumbedooh our select() calls and their select() calls.
e7ca863b04ee2a7aea7738cadbf51ce5e6c5245dhumbedooh *bangs head on wall repeatedly* But, some of the libc_r
91654e263480f0fdc2a03d782ff23f8dad07cf79humbedooh files have a DBG_MSG #define. This is moderately helpful
91814c869ca39ce45dfe147307d2a831cac6ecbehumbedooh when used with -DNO_DETACH. The kernel scheduler isn't
91654e263480f0fdc2a03d782ff23f8dad07cf79humbedooh waking up the threads on a select(). Yum. And, I bet
79c5787b92ac5f0e1cc82393816c77a006399316trawick those decrementing select calls have to do with the
79c5787b92ac5f0e1cc82393816c77a006399316trawick scheduler. Time to brush up on our OS fundamentals.
79c5787b92ac5f0e1cc82393816c77a006399316trawick * There is increasing demand from module writers for an API
c967bf3bc89e8aa60dbd30d9da388e448ddc1cc4trawick that will allow them to control the server � la apachectl.
79c5787b92ac5f0e1cc82393816c77a006399316trawick Reasons include sole-function servers that need to die if
79c5787b92ac5f0e1cc82393816c77a006399316trawick an external dependency (e.g., a database) fails, et cetera.
79c5787b92ac5f0e1cc82393816c77a006399316trawick Perhaps something in the (ever more abused) scoreboard?
79c5787b92ac5f0e1cc82393816c77a006399316trawick On the other hand, we already have a pipe that goes between parent
7b395e4e878c28a4784919cfd2e704ddd14a3390jorton and child for graceful shutdown events, along with an API that
7b395e4e878c28a4784919cfd2e704ddd14a3390jorton can be used to send a message down that pipe. In threaded MPMs,
7b395e4e878c28a4784919cfd2e704ddd14a3390jorton it is easy enough to make that one pipe be used for graceful
7b395e4e878c28a4784919cfd2e704ddd14a3390jorton and graceless events, and it is also easy to open that pipe
536e48c08d674acac5d44929318f2ad928edc361jorton to both parent and child for writing. Then we just need to
536e48c08d674acac5d44929318f2ad928edc361jorton figure out how to do graceless on non-threaded MPMs.
e81785da447b469da66f218b3f0244aab507958djorton * Allow the DocumentRoot directive within <Location > scopes? This
3e4e54d4e3fc0123c63d57aa84ac7ad7a8c73ff8jorton allows the beloved (crusty) Alias /foo/ /somepath/foo/ followed
3e4e54d4e3fc0123c63d57aa84ac7ad7a8c73ff8jorton by a <Directory /somepath/foo> to become simply
3e4e54d4e3fc0123c63d57aa84ac7ad7a8c73ff8jorton <Location /foo/> DocumentRoot /somefile/foo (IMHO a bit more legible
53e9b27aba029b18be814df40bcf6f0428771d1efuankg and in-your-face.) DocumentRoot unset would be accepted [and would
53e9b27aba029b18be814df40bcf6f0428771d1efuankg not permit content to be served, only virtual resources such as
53e9b27aba029b18be814df40bcf6f0428771d1efuankg server-info or server-status.
53e9b27aba029b18be814df40bcf6f0428771d1efuankg This proposed change would _not_ depricate Alias.
53e9b27aba029b18be814df40bcf6f0428771d1efuankg striker: See the thread starting with Message-ID:
6bb524f1895f30265a1431afc460977d391cb36bsf JLEGKKNELMHCJPNMOKHOGEEJFBAA.striker@apache.org.
ca61ccd0c306c2c72df153688ba1b49f3eceed80sf * Win32: Rotatelogs sometimes is not terminated when Apache
6bb524f1895f30265a1431afc460977d391cb36bsf goes down hard. FirstBill was looking at possibly tracking the
e6dd71992459d05a676b98b7963423dc5dc1e24aminfrin child's-child processes in the parent process.
e6dd71992459d05a676b98b7963423dc5dc1e24aminfrin stoddard: Shared scoreboard might offer a good way for the parent
e6dd71992459d05a676b98b7963423dc5dc1e24aminfrin to keep track of 'other child' processes and whack them if the child
23f1535d6a60817d2846bac0aea230ea475d7dccminfrin Other thoughts on walking the process chain using the NT kernel
23f1535d6a60817d2846bac0aea230ea475d7dccminfrin have also been proposed on APR.
23f1535d6a60817d2846bac0aea230ea475d7dccminfrin * Eliminate unnecessary creation of pipes in mod_cgid
ec7520b24cd80d34d82bbcaca153cbb23cc04bc0rjung * Combine log_child and piped_log_spawn. Clean up http_log.c.
ec7520b24cd80d34d82bbcaca153cbb23cc04bc0rjung Common logging API.
ec7520b24cd80d34d82bbcaca153cbb23cc04bc0rjung * Platforms that do not support fork (primarily Win32 and AS/400)
ec7520b24cd80d34d82bbcaca153cbb23cc04bc0rjung Architect start-up code that avoids initializing all the modules
ec7520b24cd80d34d82bbcaca153cbb23cc04bc0rjung in the parent process on platforms that do not support fork.
6249dfa569d3b4f1f539665b979a80c6e335d93etrawick * There are still a number of places in the code where we are
6249dfa569d3b4f1f539665b979a80c6e335d93etrawick losing error status (i.e. throwing away the error returned by a
0827cb14e550f6f65018431c22c2c913631c8f25kbrand system call and replacing it with a generic error code)
ae600ca541efc686b34f8b1f21bd3d0741d37674covener * Mass vhosting version of suEXEC.
cfa64348224b66dd1c9979b809406c4d15b1c137fielding * All DBMs suffer from confusion in support/dbmmanage (perl script) since
74499a117b3b2cd9666715a14f90c0e5d1a4ee8ajim the dbmmanage employs the first-matched dbm format. This is not
cfa64348224b66dd1c9979b809406c4d15b1c137fielding necessarily the library that Apache was built with. Aught to
74499a117b3b2cd9666715a14f90c0e5d1a4ee8ajim rewrite dbmmanage upon installation to bin/ with the proper library
cfa64348224b66dd1c9979b809406c4d15b1c137fielding for predictable mod_auth_dbm administration.
74499a117b3b2cd9666715a14f90c0e5d1a4ee8ajim Questions; htdbm exists, time to kill dbmmanage, or does it remain
cfa64348224b66dd1c9979b809406c4d15b1c137fielding useful as a perl dbm management example? If we keep it,
74499a117b3b2cd9666715a14f90c0e5d1a4ee8ajim do we address the issue above?
* Explore use of a post-config hook for the code in http_main.c which
* (possibly) use UUIDs in mod_unique_id and/or mod_usertrack
* shift stuff to mod_core.h
rand.c, at least.) This could be resolved with an SSL library, or
- Bring the Win9xConHook.dll from 1.3 into 2.0 (no sense till it
Message-ID: <Pine.LNX.4.44.0203011354090.16457-200000@deepthought
tree apr/apr-util, but it's a good start. There's still the
* ssl_engine_pphrase.c needs to be reworked so it is generic enough
* mod_cache: CacheEnable/CacheDisable should accept regular expressions.
* mod_mem_cache/mod_disk_cache: Need to be able to query cache
* Enable mod_cache/mod_mem_cache/mod_disk_cache to handle
* mod_mem_cache/mod_disk_cache: Complete implementing config
PR#1191: setlogin() is not called, causing problems with e.g. identd
PR#1287: add allow,deny/deny,allow warning to mod_access
PR#1117: Using NIS passwd.byname dbm files with AuthDBMUserFile
PR#2873: Feedback/Comment on APACI
PR#2431: A small addition to rotatelogs.c to improve program functionality.
PR#2889: Inclusion of RPM spec file in CVS/distributions
* orig_ct in the byterange/multipart handling may not be