time for Apache-Test 1.14?
hi all... unless mod_perl 1.99_17 is imminent I'd like to roll Apache-Test 1.14 - now that Devel::Cover works with mod_perl, 1.14 will be the first Apache-Test release that has the ability to take advantage of Devel::Cover without significant user modifications (namely due to the addition of -one-process and built-in support from TestMB). objections? --Geoff
Re: time for Apache-Test 1.14?
Geoffrey Young wrote: hi all... unless mod_perl 1.99_17 is imminent I'd like to roll Apache-Test 1.14 - now that Devel::Cover works with mod_perl, 1.14 will be the first Apache-Test release that has the ability to take advantage of Devel::Cover without significant user modifications (namely due to the addition of -one-process and built-in support from TestMB). objections? If you don't want to wait for 1.99_17 go ahead, it shouldn't make much difference, other than you will probably have to release Apache-Test 1.15 if mp is released shortly thereafter even if there will be no changes to A-T after 1.14 release (since Apache-Test will care a higher version in the mp2 package on release). Actually it's not true, while _ is in the modperl version PAUSE won't index it, so I guess it's fine for now. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: time for Apache-Test 1.14?
Geoffrey Young wrote: Stas Bekman wrote: Geoffrey Young wrote: hi all... unless mod_perl 1.99_17 is imminent I'd like to roll Apache-Test 1.14 - now that Devel::Cover works with mod_perl, 1.14 will be the first Apache-Test release that has the ability to take advantage of Devel::Cover without significant user modifications (namely due to the addition of -one-process and built-in support from TestMB). objections? If you don't want to wait for 1.99_17 go ahead, it shouldn't make much difference, other than you will probably have to release Apache-Test 1.15 if mp is released shortly thereafter even if there will be no changes to A-T after 1.14 release (since Apache-Test will care a higher version in the mp2 package on release). right. which is why I was kinda asking about the next mp2 release. if you tell me it's going to be in the next week or so it probably makes sense to hold off. if it's going to (realistically) be longer than that it makes more sense to move forward. Can't promise anything, we are sort of ready to release _17 but there is a problem with a worker mpm. Depending on how quickly it's resolved, and assuming that no other problems will be found, it'll get released. So it's up to you, probably give it a few days and if you don't see the candidate by let's say this weekend, go ahead and release it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Bye bye welcome page
* Joshua Slive [EMAIL PROTECTED] wrote: Fair warning: As the first stage of a simplification of the default config in 2.1 (only!), I'm going to remove all the html files under httpd-2.1/docs/docroot/ and replace them with an index.html file containing only htmlbodyh1It works!/h1/body/html I'm going to do this because: - there are 1000 people with 1000 other opinions. For that reason, I'm ++1 for taking this minimalistic variant. Otherwise we get never a consensus about this darn dummy page. nd -- Gefunden auf einer Webdesigner-Seite: Programmierung in HTML, XML, WML, CGI, FLASH # André Malo # http://www.perlig.de/ #
Re: cvs commit: httpd-2.0/server/mpm/winnt child.c
Jeff Trawick wrote: possible heresy The first parameter to select() on Windows is actually ignored. We should zap the logic that does the Unix-style computation of listenmaxfd and just pass in INVALID_SOCKET or 0, and add a comment that the value is ignored. /possible heresy No heresy, MSDN doc clearly says the first parm is ignored so it doesn't matter what we set it to. For clarification I can add a comment and set it to zero. Thanks, Allan
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
[EMAIL PROTECTED] wrote: ake 2004/10/06 06:33:29 Modified:modules/arch/win32 mod_win32.c server/mpm/winnt service.c support/win32 ApacheMonitor.c Log: WIN64: fix some windows specific 64bit warnings -if (!WriteConsole(hConErr, msg, strlen(msg), result, NULL) || !result) +if (!WriteConsole(hConErr, msg, (int)strlen(msg), result, NULL) || !result) -if (!WriteConsole(hConErr, count, strlen(count), result, NULL) +if (!WriteConsole(hConErr, count, (int)strlen(count), result, NULL) -lstrcpyn(szBuf, szImagePath, sPos - szImagePath); +lstrcpyn(szBuf, szImagePath, (int)(sPos - szImagePath)); -TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, strlen(szBuf)); +TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, (int)strlen(szBuf)); Please do not do that any more. I'm sorry but I'm vetoing your patches. Use the official API, it is well documented. size_t != int. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
On Wed, 06 Oct 2004 15:52:43 +0200, Mladen Turk [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ake 2004/10/06 06:33:29 Modified:modules/arch/win32 mod_win32.c server/mpm/winnt service.c support/win32 ApacheMonitor.c Log: WIN64: fix some windows specific 64bit warnings -if (!WriteConsole(hConErr, msg, strlen(msg), result, NULL) || !result) +if (!WriteConsole(hConErr, msg, (int)strlen(msg), result, NULL) || !result) -if (!WriteConsole(hConErr, count, strlen(count), result, NULL) +if (!WriteConsole(hConErr, count, (int)strlen(count), result, NULL) -lstrcpyn(szBuf, szImagePath, sPos - szImagePath); +lstrcpyn(szBuf, szImagePath, (int)(sPos - szImagePath)); -TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, strlen(szBuf)); +TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, (int)strlen(szBuf)); Please do not do that any more. I'm sorry but I'm vetoing your patches. Use the official API, it is well documented. strlen() returns size_t, TextOut() requires int; somewhere a cast is required, no? what is a better solution?
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
Jeff Trawick wrote: Please do not do that any more. I'm sorry but I'm vetoing your patches. Use the official API, it is well documented. strlen() returns size_t, TextOut() requires int; somewhere a cast is required, no? what is a better solution? That's true, but the strlen can never be int (negative). The API is DWORD meaning 32 bit unsigned integer, so either cast to API or no cast. MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
On Wed, 06 Oct 2004 16:15:51 +0200, Mladen Turk [EMAIL PROTECTED] wrote: Jeff Trawick wrote: Please do not do that any more. I'm sorry but I'm vetoing your patches. Use the official API, it is well documented. strlen() returns size_t, TextOut() requires int; somewhere a cast is required, no? what is a better solution? That's true, but the strlen can never be int (negative). The API is DWORD meaning 32 bit unsigned integer, so either cast to API or no cast. I'm confused. The only TextOut() doc I can find says int, not DWORD. Can you provide a link? Here is where I looked: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_5yd0.asp
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
Mladen Turk wrote: That's true, but the strlen can never be int (negative). The API is DWORD meaning 32 bit unsigned integer, so either cast to API or no cast. You are correct that for WriteConsole the cast should have been DWORD - I will fix that, thanks For TextOut and lstrcpyn the parameter is in fact int so we either have to cast to int and assmume the string length will never by 2Gig (seems reasonable), or we need to explicitly check for strlen 2Gig and fail if it is, or use a different API (if there is one). What do you suggest? Allan
Re: Bye bye welcome page
* Joshua Slive [EMAIL PROTECTED] |__ Tue, Oct 05, 2004 at 01:30:23PM -0400: (only!), I'm going to remove all the html files under httpd-2.1/docs/docroot/ and replace them with an index.html file containing only htmlbodyh1It works!/h1/body/html +1 Good call, Josh. -- Chip Cuccio| [EMAIL PROTECTED] NORLUG Sysadmin Webmaster| http://norlug.org/~chipster/ Northfield Linux Users' Group | Northfield, Minnesota USA pgpGnrTp9YBw3.pgp Description: PGP signature
Re: Bye bye welcome page
On Wed, 6 Oct 2004, [ISO-8859-15] André Malo wrote: - there are 1000 people with 1000 other opinions. For that reason, I'm ++1 for taking this minimalistic variant. Otherwise we get never a consensus about this darn dummy page. That's an exceedingly good point. Make it so. :) +1. --Cliff
Re: Bye bye welcome page
On 06.10.2004, at 18:07, Cliff Woolley wrote: On Wed, 6 Oct 2004, [ISO-8859-15] André Malo wrote: - there are 1000 people with 1000 other opinions. For that reason, I'm ++1 for taking this minimalistic variant. Otherwise we get never a consensus about this darn dummy page. That's an exceedingly good point. Make it so. :) +1. Same here, +1 - although... ;) Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: Bye bye welcome page
On Tue, 5 Oct 2004, Graham Leggett wrote: Joshua Slive wrote: No, because this is a very confusing and ambiguous statement from the perspective of a random web surfer who stumbles on the page. Their response is Why are you saying I installed a webserver on my computer? This must be some kind of security breach. Call in the marines! (And I'm hardly exagerating!) Point... How about The website you have accessed has not yet been configured. Please try to access this website again later.? It's directed at end users, and does not imply anywhere that the server might be running on their local machine. My opinion is that the shorter message is better because, by the fact that it gives no information at all, it is less likely to be misinterpreted to mean something that the website owner doesn't intend. I won't object if someone wants to put another piece of text there, as long as it doesn't start us back on the same road we left 5+ years ago with this page. Joshua.
Re: Bye bye welcome page
Joshua Slive wrote: My opinion is that the shorter message is better because, by the fact that it gives no information at all, it is less likely to be misinterpreted to mean something that the website owner doesn't intend. I won't object if someone wants to put another piece of text there, as long as it doesn't start us back on the same road we left 5+ years ago with this page. In that case why not just have the default page be an empty drectory listing? If I was a newbie, and I saw a page that says `it worked`, my immediate reaction would be `what worked?` and I would start asking the exact questions we`re trying to stop people from asking. Regards, Graham --
Re: Bye bye welcome page
From what I can see, the reason for providing a short and simple welcome page is to avoid confusing people by giving them too much information. The question I would ask is, are you just trading one set of problems for another? How many people are we going to confuse by not giving enough information? You may be climbing out of one boat full of problems, just to climb into another. Translation issues aside, personally the only thing that I see wrong with the welcome page is the fact that it keeps referring to this system. Cut the first paragraph and the rest is fine. I guess the point is, too much information might be a problem in this case, but then so is too little. Just my 1 of 1000 opinions. Brad [EMAIL PROTECTED] Wednesday, October 06, 2004 11:12:33 AM On Tue, 5 Oct 2004, Graham Leggett wrote: Joshua Slive wrote: No, because this is a very confusing and ambiguous statement from the perspective of a random web surfer who stumbles on the page. Their response is Why are you saying I installed a webserver on my computer? This must be some kind of security breach. Call in the marines! (And I'm hardly exagerating!) Point... How about The website you have accessed has not yet been configured. Please try to access this website again later.? It's directed at end users, and does not imply anywhere that the server might be running on their local machine. My opinion is that the shorter message is better because, by the fact that it gives no information at all, it is less likely to be misinterpreted to mean something that the website owner doesn't intend. I won't object if someone wants to put another piece of text there, as long as it doesn't start us back on the same road we left 5+ years ago with this page. Joshua.
RE: Bye bye welcome page
-Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 8:36 PM To: [EMAIL PROTECTED] Subject: Re: Bye bye welcome page Joshua Slive wrote: My opinion is that the shorter message is better because, by the fact that it gives no information at all, it is less likely to be misinterpreted to mean something that the website owner doesn't intend. I won't object if someone wants to put another piece of text there, as long as it doesn't start us back on the same road we left 5+ years ago with this page. In that case why not just have the default page be an empty drectory listing? If I was a newbie, and I saw a page that says `it worked`, my immediate reaction would be `what worked?` and I would start asking the exact questions we`re trying to stop people from asking. We can always go with simply displaying a meaningless word like 'Waboozle'. Sander
RE: Bye bye welcome page
On Wed, 6 Oct 2004, Sander Striker wrote: We can always go with simply displaying a meaningless word like 'Waboozle'. I can see the bugtraq advisory now: Waboozle virus on the loose. ;)
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
Allan Edwards wrote: Mladen Turk wrote: That's true, but the strlen can never be int (negative). The API is DWORD meaning 32 bit unsigned integer, so either cast to API or no cast. You are correct that for WriteConsole the cast should have been DWORD - I will fix that, thanks Look, I'm sorry if you found my initial post offending cause I've used the 'v' word, but the way you've headed would make almost any CRT lib call casted, and that just doesn't make sense to me. Both apr and libhttpd has more then 100 of those when /Wp64 is used, so IMO we would just hide the problems under carpet if just casting every 64-32 warning found. For example inside http_protocol.c you have: 'int len = strlen(method)', that is wrong by all means, but I wouldn't write that as 'int len = (int)strlen(method)' just to make the compiler happy, but rather use 'size_t len = strlen(method)'. For TextOut and lstrcpyn the parameter is in fact int so we either have to cast to int and assmume the string length will never by 2Gig (seems reasonable), or we need to explicitly check for strlen 2Gig and fail if it is, or use a different API (if there is one). Well, that one is probably OK. I was talking about the concept of not casting just for the sake of making compiler happy. Regards, Mladen. smime.p7s Description: S/MIME Cryptographic Signature
[STATUS] (apache-1.3) Wed Oct 6 23:45:07 EDT 2004
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2004/09/30 17:12:41 $] Release: 1.3.32-dev: In development. Jim proposes a release top of Sept. 1.3.31: Tagged May 7, 2004. Announced May 11, 2004. 1.3.30: Tagged April 9, 2004. Not released. 1.3.29: Tagged October 24, 2003. Announced Oct 29, 2003. 1.3.28: Tagged July 16, 2003. Announced ?? 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: PROPOSED PATCHES FOR THIS RELEASE: *) mod_rewrite:Fix query string handling for proxied URLs. PR 14518. modules/mappers/mod_rewrite.c: r1.259 (2.x patch - need 1.3 version) +1: nd *) mod_log_config: Cleanup log_header_out function to allow multiple headers like Set-Cookie to be logged properly. PR 27787 modules/loggers/mod_log_config.c: r1.116 (2.x patch - need 1.3 version) jerenkrantz asks: Isn't this what apr_table_merge is for? nd replies: yep. But cookies won't be merged, because browsers don't support it. jerenkrantz: Couldn't we copy the table and merge the values somehow? This just seems like a lot of code to duplicate what we have already. *shrug* +1: nd, jerenkrantz RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * PR: 27023 Cookie could not delivered if the cookie made before proxy module. * isn't ap_die() broken with recognizing recursive errors Message-Id: [EMAIL PROTECTED] +1: jeff, jim * Current vote on 3 PRs for inclusion: Bugz #17877 (passing chunked encoding thru proxy) (still checking if RFC compliant... vote is on the correctness of the patch code only). +1: jim, chuck, minfrin Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers
[STATUS] (httpd-2.1) Wed Oct 6 23:45:14 EDT 2004
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2004/09/03 02:47:19 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.0 : in development Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the PatchAvailable bugs in the bug database. Append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * When the CVS-SVN is done, there's a bogus avendor branch that should be removed from most files. The branch was created 4/27/2004. It's safest (and easiest) for now just to leave it in there; the MAIN branch and the APACHE_2_0_BRANCH are untouched and unharmed. --jwoolley RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 CURRENT VOTES: * Promote mod_cache from experimental to non-experimental status (keep issues noted below in EXPERIMENTAL MODULES as items to be addressed as a supported module). +1: jim, bnicholes -0: jerenkrantz -1: stoddard There are a couple of problems that need to be resolved before this module is moved out of experimental. 1) We need to at least review and comment on the RFC violations 2) Resolve issue of how to cache page fragements (or perhaps -if- we want to cache page fragements). Today, mod_cache/mod_mem_cache 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). jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla for mod_cache (see 'RFC 2616 violations' below). I think fixing them is a pre-requisite before it isn't experimental. * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * 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: [EMAIL PROTECTED] 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
[STATUS] (httpd-2.0) Wed Oct 6 23:45:11 EDT 2004
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2004/10/05 00:29:48 $] Release: 2.0.53 : in development 2.0.52 : released September 28, 2005 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 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 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 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the PatchAvailable bugs in the bug database. Append a comment saying Reviewed and tested. * Open bugs in the bug database. RELEASE SHOWSTOPPERS: PATCHES TO BACKPORT FROM 2.1 [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] *) mod_auth_ldap: Handle the inconsistent way in which the MS LDAP library handles special characters. http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12919 PR 24437 +1: minfrin *) mod_ldap: fix a bogus error message to tell the user which file is causing a potential problem with the LDAP shared memory cache. modules/ldap/util_ldap.c: 1.14 PR 31431 +1: minfrin, bnicholes *) mod_ldap: prevent the possiblity of an infinite loop in the LDAP statistics display. modules/ldap/util_ldap_cache_mgr.c: 1.11 PR 29216 +1: minfrin, bnicholes *) apxs: fix handling of -Wc/-Wl and -o mod_foo.so. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/support/apxs.in?r1=1.62r2=1.64 PR: 31448 +1: jorton, jerenkrantz *) Fix ap_save_brigade's handling of ENOTIMPL setaside functions. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/util_filter.c?r1=1.100r2=1.101 PR: 31247 jerenkrantz comments: This needs the final patch posted to [EMAIL PROTECTED] +1: jorton *) Correctly store cache content type. PR 30278 modules/experimental/mod_disk_cache.c?r1=1.62r2=1.63 +1: stoddard, jerenkrantz, minfrin *) Do not store aborted content. PR 21492. modules/experimental/mod_disk_cache.c?r1=1.63r2=1.64 +1: stoddard, jerenkrantz, minfrin *) Try to correctly follow RFC 2616 13.3 on validating stale cache responses by teaching mod_cache's cache_select_url and cache_save_filter how to deal with this corner case. modules/experimental/cache_storage.c?r1=1.39r2=1.40 modules/experimental/cache_util.c?r1=1.34r2=1.35 modules/experimental/mod_cache.c?r1=1.91r2=1.92 modules/experimental/mod_cache.h?r1=1.50r2=1.51 modules/experimental/mod_disk_cache.c?r1=1.64r2=1.65 modules/experimental/mod_mem_cache.c?r1=1.117r2=1.118 +1: stoddard, jerenkrantz, minfrin *) mod_rewrite: Fix 0 bytes write into random memory position. PR 31036. (2.0 + 1.3) http://www.apache.org/~nd/dbmmap_1.3.patch
