Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Randy Kobes wrote: On Fri, 9 Mar 2007, Joe Schaefer wrote: Randy, do you know why we use the APR_FILE_NOCLEANUP flag? Maybe we should just remove that and see if it fixes the problem Vinay is seeing. Hi Steve, and all, If you remember from http://marc.theaimsgroup.com/?t=11533762941r=1w=2 there was a problem with stray temp files in apreq remaining after uploads; we came up with a fix that worked most of the time, but Vinay has come up with something that appears better, and more understandable. The attached diff against library/util.c (in the svn sources) works for me in getting multiple invocations of the glue/perl/t/apreq/upload.t to pass; if you have time, could you try it out to see how it fares on your system? Thanks. I tried your patch with the current svn version (revision 518242), but I'm still seeing intermittent failures (usually in tests 15, 16 and/or 20) either when I run nmake test from the top-level, or when I run: perl -Iblib/arch -Iblib/lib t/TEST -verbose=1 t/apreq/upload.t from the glue/perl sub-directory :-( I'm running perl-5.8.8, apache-2.2.2 and mod_perl-2.0.3 (RC3, I think). Do I need to update anything there? -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Steve Hay [EMAIL PROTECTED] writes: I tried your patch with the current svn version (revision 518242), but I'm still seeing intermittent failures (usually in tests 15, 16 and/or 20) either when I run nmake test from the top-level, or when I run: perl -Iblib/arch -Iblib/lib t/TEST -verbose=1 t/apreq/upload.t from the glue/perl sub-directory :-( Posting some diagnostic output might help. Anything in the error logs? Are you seeing any lingering tempfiles, and if so, are they prefixed with apreq (ie coming from apreq_file_mktemp), or are they from the test scripts? Randy, I see a lot of stuff like unlink $file if -f $file; in the upload.t tests, which might need to be changed to unlink $file or die Can't unlink $file: $!; -- Joe Schaefer
CGI app reports broken pipe error
Hi. I have a custom CGI application writing binary data to stdout. Recently, probably after some upgrade, I begin receiving write errors with the system error Broken pipe. The only way to proceed writing is to discard the data portion I'm trying to write and continue. Can someone advice how to debug this and find the issue? Also, are there any know recent changes (from this year beginning/last year end) which could have caused this? I'm using CentOS 4.4, Apache version 2.0.52. Thanks, Stas.
Re: sed filter module
Just wanted to add my two cents worth...
We are using mod_line_edit a lot and would like to see a similar
functionality coming with Apache by default. :-)
When I am correct mod_line_edit has the 'wrong' license model for being
included into Apache by default.
Just for your infomation: There are more modules having a similar
functionality:
http://mod-replace.sourceforge.net/
http://yomi.2288.org/forum/ftopic22.html (given by
http://modules.apache.org/search?id=857)
http://happygiraffe.net/mod_sed.html (VERY old)
All modules are missing a feature we would like to see: Like in
mod_rewrite's RewriteMap it would be cool to specify a function being
called on the argument while replacing. E.g.:
RewriteBodyLine 'http://(.*?)/(.*)/(.*)'
'http://${LOWERCASE:$1}/${MD5:$2}/$3'
... as I told before: Just my $.2
P.S.: And I vote for a better name like 'mod_filter_pcre' ...
Re: sed filter module
On Wed, 14 Mar 2007 10:07:49 +0100
Frank [EMAIL PROTECTED] wrote:
Just wanted to add my two cents worth...
We are using mod_line_edit a lot and would like to see a similar
functionality coming with Apache by default. :-)
Sounds like a vote.
When I am correct mod_line_edit has the 'wrong' license model for
being included into Apache by default.
Indeed. When my modules have been integrated into the standard
distribution in the past, they've moved to the Apache license.
It's not a problem when there's a good reason for it.
Just for your infomation: There are more modules having a similar
functionality:
Interesting!
http://mod-replace.sourceforge.net/
That one's genuinely interesting. Looks like an alternative
reverse-proxy solution, combining filtering with the mod_proxy cookie
rewriting that was missing in 2.0. But it buffers an entire response
in memory, which limits its usefulness.
http://yomi.2288.org/forum/ftopic22.html (given by
http://modules.apache.org/search?id=857)
My chinese isn't up to finding a download link there!
http://happygiraffe.net/mod_sed.html (VERY old)
No thank you:-)
All modules are missing a feature we would like to see: Like in
mod_rewrite's RewriteMap it would be cool to specify a function being
called on the argument while replacing. E.g.:
RewriteBodyLine 'http://(.*?)/(.*)/(.*)'
'http://${LOWERCASE:$1}/${MD5:$2}/$3'
This kind of feature is on the to-do list, amongst some
hacks-in-progress that have yet to reach the mod_line_edit site.
This is actually what alarms me somewhat about the prospect of
a different but near-identical module in /trunk/: it leaves me
either abandoning or redoing some of this stuff.
P.S.: And I vote for a better name like 'mod_filter_pcre' ...
But it isn't. It offers string as well as regex matching!
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: sed filter module
On Mar 14, 2007, at 5:07 AM, Frank wrote:
RewriteBodyLine 'http://(.*?)/(.*)/(.*)' 'http://${LOWERCASE:$1}/$
{MD5:$2}/$3'
Yeah, that would be useful... Of course, the main issue is
that whereas mod_rewrite can afford to be dog slow, because,
after all, the URLs aren't *that* big, in-place rewriting
of content can't be. The more complex the functionality,
the slower it will be... :/
Re: sed filter module
On Wed, 14 Mar 2007 09:25:11 -0400
Jim Jagielski [EMAIL PROTECTED] wrote:
On Mar 14, 2007, at 5:07 AM, Frank wrote:
RewriteBodyLine 'http://(.*?)/(.*)/(.*)' 'http://${LOWERCASE:$1}/$
{MD5:$2}/$3'
Yeah, that would be useful... Of course, the main issue is
that whereas mod_rewrite can afford to be dog slow, because,
after all, the URLs aren't *that* big, in-place rewriting
of content can't be. The more complex the functionality,
the slower it will be... :/
Solved in mod_line_edit: the code path for extra functionality
(such as per-rule conditional execution and environment variable
substitution) is invoked only when required.
As for the particular case Frank asked for, that works by
expanding the union to include a function pointer alongside
the strmatch and regexp cases. So it's also a per-rule
configuration flag, and never touches the code path except
where explicitly invoked.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: sed filter module
On Wed, 14 Mar 2007 13:45:47 + Nick Kew [EMAIL PROTECTED] wrote: As for the particular case Frank asked for, that works by expanding the union to include a function pointer alongside the strmatch and regexp cases. So it's also a per-rule configuration flag, and never touches the code path except where explicitly invoked. Sorry, I meant the to field becomes a union which may be a function. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: sed filter module
On Tue, Mar 13, 2007 at 09:24:25AM -0400, Jim Jagielski wrote:
There have been times when having a simple sed filter in Apache
would be useful... I used to use just ext_filter to do this,
but this got more and more painful the more I used it. So awhile
ago I made mod_sed_filter which I find pretty useful. I've just
built and tested in with 2.2 and trunk...
Anyone mind if I fold it into trunk and maybe have us
consider making it part of 2.2 (even under experimental)?
No docs yet but the code is:
http://people.apache.org/~jim/code/mod_sed_filter.c
It would be good to have a simple filter like this in the tree. From a
quick review:
1) the filtering logic is broken and will consume RAM proportional to
response size. The mantra for writing output filters should be: read
buckets, process buckets, pass buckets, repeat
2) 200-line functions are hard to read :)
...otherwise looks like nice simple code. I don't see a *big* issue
with the name implying likeness-of-sed. mod_{pcre,text}_filter or
something is as good.
Nick, are you actually planning to submit mod_line_edit for inclusion in
the tree?
joe
Re: sed filter module
On Wed, 14 Mar 2007 14:32:13 + Joe Orton [EMAIL PROTECTED] wrote: 1) the filtering logic is broken and will consume RAM proportional to response size. I must've missed that when I looked. I thought it used the same logic as mod_line_edit, which is very careful about that. Oh, I guess you mean the copying to get a null-terminated string when applying a regexp? And I see it's repeated for every regexp (ouch)! mod_line_edit uses a local pool which is cleared at the end of each brigade, and avoids multiple copies of the same buffer. 2) 200-line functions are hard to read :) mod_line_edit does the same there, but that's definitely being split (not least so that the actual search-and-replace function can be re-used in a companion input filter). And given that it's unusually well-commented and half of it features as example code in my book, I don't think it's hard to read:-) Nick, are you actually planning to submit mod_line_edit for inclusion in the tree? The subject hasn't arisen until this thread (which caught me rather off-balance), but I'll be happy to include it if there's demand. As I hinted, there are some enhancements in the pipeline. If it goes in to trunk, a roadmap would probably be in order. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: sed filter module
On Mar 14, 2007, at 11:01 AM, Nick Kew wrote: Oh, I guess you mean the copying to get a null-terminated string when applying a regexp? And I see it's repeated for every regexp (ouch)! mod_line_edit uses a local pool which is cleared at the end of each brigade, and avoids multiple copies of the same buffer. Hmmm... I'm confused. The way I do it is: loop over sed scripts loop over buckets read bucket make copy of bucket data for regex comparison so everytime we read in bucket data, I have to make a null-termed string. It changes with each bucket. So I don't understand the issue with it being repeated for every regexp. How can that be avoided? I reuse allocated space (I don't just simply keep making strdups)... so yeah, there will be a chunk of allocated spool still hanging around. So maybe making that a subpool and then clearing/destroying it would be best.
Re: sed filter module
On Wed, Mar 14, 2007 at 03:01:53PM +, Nick Kew wrote: On Wed, 14 Mar 2007 14:32:13 + Joe Orton [EMAIL PROTECTED] wrote: 1) the filtering logic is broken and will consume RAM proportional to response size. I must've missed that when I looked. I thought it used the same logic as mod_line_edit, which is very careful about that. It looks just as broken to me. It will read() from every bucket in the input brigade without passing anything on, so you guarantee that the entire response is mapped into RAM for a single filter invocation. joe
Re: sed filter module
On Wed, 14 Mar 2007 15:27:44 + Joe Orton [EMAIL PROTECTED] wrote: On Wed, Mar 14, 2007 at 03:01:53PM +, Nick Kew wrote: On Wed, 14 Mar 2007 14:32:13 + Joe Orton [EMAIL PROTECTED] wrote: 1) the filtering logic is broken and will consume RAM proportional to response size. I must've missed that when I looked. I thought it used the same logic as mod_line_edit, which is very careful about that. It looks just as broken to me. It will read() from every bucket in the input brigade without passing anything on, Yes, the processing unit is the brigade. A bucket could easily be just a byte or two, whereas a brigade is more likely to be a sensible amount of the data (such as the 8K seen when mod_proxy is driving, and which is the most common usage case). so you guarantee that the entire response is mapped into RAM for a single filter invocation. Nope. Just one brigades worth at a time. And the most likely case for that to be an entire document is when it's a static file, and document == brigade == bucket. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: sed filter module
On Wed, 14 Mar 2007 11:15:00 -0400 Jim Jagielski [EMAIL PROTECTED] wrote: On Mar 14, 2007, at 11:01 AM, Nick Kew wrote: Oh, I guess you mean the copying to get a null-terminated string when applying a regexp? And I see it's repeated for every regexp (ouch)! mod_line_edit uses a local pool which is cleared at the end of each brigade, and avoids multiple copies of the same buffer. Hmmm... I'm confused. The way I do it is: loop over sed scripts loop over buckets read bucket make copy of bucket data for regex comparison You're right, I was confused, and mod_line_edit does exactly the same. What I'd like to get rid of is that copy inside the loop: once copied, the copied bucket data should be reusable for other scripts. But as we both found, that's harder! -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Check for IP address in network/netmask
Hi, what is the standard way to store network/netmask combos, and check if a client IP address is contained in them? I once saw a function for that but I can't find it now. Maybe it was apr_ipsubnet_test(), as used in modules/aaa/mod_authz_host.c. Probably this does what I need. I find further code in apr/test/testipsub.c. However, I would appreciate pointers to possible alternatives. I would also appreciate pointers to examples where this is used in a module other than mod_authz_host. Thanks! Peter -- SUSE LINUX Products GmbH Bug, bogey, bugbear, bugaboo: Research Development A malevolent monster (not true?); Some mischief microbic; What makes someone phobic; The work one does not want to do. From: Chris Young (The Omnificent English Dictionary In Limerick Form) pgpu5dv1TYPDe.pgp Description: PGP signature
Re: sed filter module
On Wed, Mar 14, 2007 at 03:45:05PM +, Nick Kew wrote: Nope. Just one brigades worth at a time. And the most likely case for that to be an entire document is when it's a static file, and document == brigade == bucket. I'm not sure what you're saying here. Which do you agree with: a) size of data represented by a brigade is limited only by apr_off_t b) httpd does use brigades representing large amounts of content e.g. containing FILE or CGI/PIPE buckets c) if you loop through all the buckets in a brigade calling read() on every one, you map all the data represented by the brigade into RAM d) writing filters which use RAM proportional to content size is bad joe
Re: CGI app reports broken pipe error
On 3/14/07, Stas Oskin [EMAIL PROTECTED] wrote: Hi. I have a custom CGI application writing binary data to stdout. Recently, probably after some upgrade, I begin receiving write errors with the system error Broken pipe. that should mean that the web client disconnected, and your CGI shouldn't keep pumping out data Can someone advice how to debug this and find the issue? Also, are there any know recent changes (from this year beginning/last year end) which could have caused this? prefork MPM and strace -f
Re: sed filter module
On Wed, 14 Mar 2007 16:56:41 + Joe Orton [EMAIL PROTECTED] wrote: On Wed, Mar 14, 2007 at 03:45:05PM +, Nick Kew wrote: Nope. Just one brigades worth at a time. And the most likely case for that to be an entire document is when it's a static file, and document == brigade == bucket. I'm not sure what you're saying here. Which do you agree with: a) size of data represented by a brigade is limited only by apr_off_t ditto size of a bucket b) httpd does use brigades representing large amounts of content e.g. containing FILE or CGI/PIPE buckets Again, the unit of indefinite size is the bucket c) if you loop through all the buckets in a brigade calling read() on every one, you map all the data represented by the brigade into RAM Indeed. d) writing filters which use RAM proportional to content size is bad Yep. Now, what leads you to suppose mod_line_edit uses RAM proportional to content size? Other than when the entire contents arrive in a single bucket? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: sed filter module
On 3/14/07, Nick Kew [EMAIL PROTECTED] wrote: to content size? Other than when the entire contents arrive in a single bucket? Uh, a file bucket? -- justin
How do I interface with language negotiation
Hi. Finally I am putting the pieces together for mod_i18n. The one thing that is missing is that it needs to talk to the language negotiation. I want language negotiation to select one out of a set of several languages I can deliver. Sincerely, Joachim
Re: 3.0 - Proposed Requirements
On Mon, Mar 12, 2007 at 02:53:14PM -0700, Shankar Unni wrote: Paul Querna wrote: - High Performance Event System Calls (KQueue, Event Ports, EPoll, I/O Completion Ports). This is a tricky area. You definitely don't want to tie yourself to a small subset of OSes. The real magic trick, however, would be to come up with an abstraction that can take advantage of these if available, but still be able to fall back to conventional I/O if none of these are available.. This is what libevent does. It has a clean and well-designed API, and was released under a 3-clause BSD license, which I hope is compatible with our Apache License (v2). -aaron
Re: sed filter module
As a rough proof of concept, I refactored the design, allowing for the pattern matching and substitution to be done as soon as we have a line. Also is some rough ability to pass the data to the next filter after we get more than ~AP_MIN_BYTES_TO_WRITE bytes. Doesn't alleviate all the problems, but it allows for us to pass data quicker (we still have the issue where we need to fully read in the bb though...) It's rough but passes superficial testing... More work needs to be done, but more people could work on it if I just commit to trunk :) Same URL, different version: http://people.apache.org/~jim/code/mod_sed_filter.c
Re: sed filter module
On Wed, Mar 14, 2007 at 06:38:48PM +, Nick Kew wrote:
Now, what leads you to suppose mod_line_edit uses RAM proportional
to content size? Other than when the entire contents arrive in a
single bucket?
Because it implements the naive filter implementation, equivalent to:
e = APR_BRIGADE_FIRST(bb);
while (e != APR_BRIGADE_SENTINEL(bb)) {
apr_bucket_read(e, ...);
...process bucket without passing on to f-next or deleting...
e = APR_BUCKET_NEXT(e);
}
for the general case given bb contains a single FILE bucket, or a
CGI/PIPE bucket, or any morphing bucket type which doesn't represent a
chunk of memory, this does:
After Iter# Contents of bb Heap memory used
1 HEAP FILE 8K
2 HEAP HEAP FILE 16K
3 HEAP HEAP HEAP FILE 24K
...
n HEAP*n n*8K
where n ~= file size / 8K; FILE buckets will also morph into MMAP
buckets so the practice is a bit more complicated but this illustrates
the point... and the 8K is really 8000 bytes.
joe
Re: New to module development
Joe Lewis wrote: It should be provided with your distribution : apache-devel is the RPM you need. And probably apr-devel and apr-util-devel -- Drew
Re: CGI app reports broken pipe error
Hi. that should mean that the web client disconnected, and your CGI shouldn't keep pumping out data So the moment the client is gone, and the CGI app attempts to send data, it will receive broken pipe (as there indeed no pipe anymore)? Is this the only reason for the error? prefork MPM and strace -f Thanks, will try them. Regards, Stas.
Apache with ssl on kernel 2.6 is slow
Hi, I recently shifted our apache server from linux kenrel 2.4.19 to 2.6 and openssl 0.9.8. I have found out that it has become very slow under moderate load when using ssl. I have compared the performance using Microsoft ACT tool. Linux kernel 2.6 is running with NPTL configuration. Please guide me how to debug the situation. Regards, Satinder Singh The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
[STATUS] (httpd-trunk) Wed Mar 14 23:46:31 2007
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/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: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2
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
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2
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.
CURRENT VOTES:
* 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 (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?
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(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 things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr-main)
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. MAY
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at
[STATUS] (httpd-2.0) Wed Mar 14 23:47:32 2007
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2007-02-16 15:40:35 -0500 (Fri, 16 Feb 2007) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.60 : in maintenance 2.0.59 : released July 28, 2006 as GA. 2.0.58 : released May 1, 2006 as GA. 2.0.57 : tagged April 19, 2006, not released. 2.0.56 : tagged April 16, 2006, not released. 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 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 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: * mod_proxy: ProxyTimeout (and others) ignored due to not merging the *_set params. PR# 11540 Trunk version of patch: http://svn.apache.org/viewvc?view=revrevision=507516 2.0 version: http://people.apache.org/~jim/patches/httpd-2.0-proxy.patch +1: jim, minfrin PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] *) Reverse Proxy fixes: Location bug and Cookie support Patch
