APACHE 2.0 STATUS: -*-text-*-
-Last modified at [$Date: 2002/03/22 15:13:14 $]
+Last modified at [$Date: 2002/03/26 20:35:50 $]
Release:
- 2.0.34 : in development
- 2.0.33 : tagged March 6, 2002.
- 2.0.32 : released Feburary 16, 2002.
+ 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
+ 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
FINAL RELEASE SHOWSTOPPERS:
- * If any request gets to 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. 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: <065701c14526$495203b0$96c0b0d0@roweclan.net>
- we need to look at halting this in the 'default handler' case,
- and that implies pushing the 'handler election' into the request
- internal processing phase from the run request phase.
- Jim asks: would a stopgap be something bogus like adding another
- flag to request_rec ala eos_sent and before we OK, if not set
- force 500?
- Jeff says: reviewing the original message and the one
- follow-up (also from OtherBill) it looks like OtherBill had a
- good handle on the problem, though I wonder why not just put a
- simple check in default_handler to see if dir/file_walk has
- been done (a footprint left by dir/file_walk doesn't have to
- be in request_rec; a better place is core_request_config)
-
- 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. Please vote.
- not a showstopper: gregames
- showstopper:
-
* API changes planned for 2.0 that should happen before the
GA release:
* Free lists for bucket allocation
Aaron says: This is not a showstopper, these problems have existed
for as long as I can remember. It would be nice to fix
them but they are not new.
- Not a showstopper: Jeff, Aaron, BillS
+ Not a showstopper: Jeff, Aaron, BillS, gregames
CURRENT VOTES:
- * Should we always build binaries statically unless otherwise
+ * Should we always build [support*] binaries statically unless otherwise
indicated?
Message-ID: <20020129210006.B23512@Lithium.MeepZor.Com>
- +1: Ken
+ +1: Ken, *wrowe [they are PITAs on OSX]
-1: Justin, Ian
* If the parent process dies, should the remaining child processes
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, Jim, Justin
Have 2 parents: +1: Jim
- -1: Justin
+ -1: Justin, wrowe [for 2.0]
+0: Martin (while standing by, could it do
something useful?)
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
+ * 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: <065701c14526$495203b0$96c0b0d0@roweclan.net>
+ [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
+ or we break modules that are unwilling to hook map_to_storage.
+
+ * Rewrite core_output_filter. It is nearly impossible to support
+ it with predictable results as it is implemented now.
+
* Convert all instances of the old apr_lock_t type to the new
types.
Status: Aaron has converted all but the perchild MPM to
to read from.
Proposed solution in:
Message-ID: <3C36ADAF.60601@cnet.com>
+ Update 3/23/2002: solution implemented for mod_cgi, mod_cgid remains
+ to be fixed
* Try to get libtool inter-library dependency code working on AIX.
Message-ID: <cm3n10lx555.fsf@rdu163-40-092.nc.rr.com>
stoddard: Not fixed. 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.
* Win32: Add a simple hold console open patch (wait for close or
the ESC key, with a nice message) if the server died a bad
projects / apache / blobdiff