[STATUS] (httpd-2.1) Wed Jan 14 23:45:16 EST 2004

APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2004/01/04 15:08:00 $] 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 proj

[STATUS] (httpd-2.0) Wed Jan 14 23:45:11 EST 2004

APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2004/01/14 21:55:37 $] Release: 2.0.49 : in development 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.

[STATUS] (apache-1.3) Wed Jan 14 23:45:06 EST 2004

APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2003/11/27 17:03:36 $] Release: 1.3.30-dev: In development 1.3.29: Tagged October 24, 2003. Announced Oct 29, 2003. 1.3.28: Tagged July 16, 2003. Announced ?? 1.3.27: Tagged September

Re: apache bug archive?

On Thu, 15 Jan 2004 Erik Abele wrote : > Have a look at the old gnats bug-archive (ranging back to '96): > http://archive.apache.org/gnats/ Thanks! I was initially confused by the big number of modules. I guess the module "general" should be my focus. On the other hand, is it true all the worker

Re: apache bug archive?

Have a look at the old gnats bug-archive (ranging back to '96): http://archive.apache.org/gnats/ Cheers, Erik On 15.01.2004, at 02:09, Min Xu(Hsu) wrote: Hi all, I wonder where can I find apache bug archive that goes further back than the bugzilla database? I am interested in searching through

apache bug archive?

Hi all, I wonder where can I find apache bug archive that goes further back than the bugzilla database? I am interested in searching through the bug database and picking out those data race related bugs. It seems that recent apache codebase is relatively bugfree with respect to these kind of bugs.

Re: SSL renegotiation bug

On Wed, Jan 14, 2004 at 03:27:23PM -0600, Ben Collins-Sussman wrote: > On Tue, 2004-01-13 at 17:26, Joe Orton wrote: > > > Is there still a TCP connection between the client and server at this > > point? If so, you can identify the server child in question via the > > server-status output or "net

Re: httpd 2.1 project plan vs "LINK" method

Roy T. Fielding wrote: On Wednesday, January 14, 2004, at 01:04 PM, Julian Reschke wrote: From...: "- Implementation of the "LINK" Method" Can anybody tell me what this is? See RFC 2068, section 19.6.1.2 and 19.6.2.4 (you might want to look at

Re: SSL renegotiation bug

On Tue, 2004-01-13 at 17:26, Joe Orton wrote: > Is there still a TCP connection between the client and server at this > point? If so, you can identify the server child in question via the > server-status output or "netstat -pt", and strace the process to see > what it's doing. After the hang, 'n

Re: httpd 2.1 project plan vs "LINK" method

On Wednesday, January 14, 2004, at 01:04 PM, Julian Reschke wrote: From...: "- Implementation of the "LINK" Method" Can anybody tell me what this is? See RFC 2068, section 19.6.1.2 and 19.6.2.4 (you might want to look at the description of PATCH

httpd 2.1 project plan vs "LINK" method

From...: "- Implementation of the "LINK" Method" Can anybody tell me what this is? Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: apr buildconf & libtool

On Wed, Jan 14, 2004 at 07:21:08PM +, Patrick Welche wrote: > % sh buildconf > rebuilding srclib/apr/configure > buildconf: checking installation... > buildconf: autoconf version 2.59 (ok) > buildconf: libtool version 1.5a (ok) > Copying libtool helper files ... > cat: aclocal.m4: No such file

Re: [PATCH 1.3] work around some annoyances with ab error handling

+1, though it would probably be better to add a parameter to err to pass errno (or 0) rather than using the global in this way. Roy

apr buildconf & libtool

% sh buildconf rebuilding srclib/apr/configure buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: libtool version 1.5a (ok) Copying libtool helper files ... cat: aclocal.m4: No such file or directory buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m

Re: [Bug?] cvs commit: httpd-2.0/server core.c

>What about the case where they did have sendfile, but did not use large >file support? [Did/Do] we attempt to test the EnableSendfile logic? Yes, that happens in core.c/default_handler() when apr_file_open() is called. If the build has send_file support then the APR_SENDFILE_ENABLED flag is pas

Re: cvs commit: httpd-2.0/server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h

Bill Stoddard wrote: Checkout this patch. I -know- state AP_MPMQ_RESTARTING does not exist in ap_mpm.h (so this patch will not compile) but consider it for purposes of discussion. The parent process always goes through master_main() and master_main() can distinguish between stopping and grace

Re: cvs commit: httpd-2.0/server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h

Jeff Trawick wrote: Bill Stoddard wrote: Do you know of any cases that actually require mpm_state to be updated in ap_signal_parent()? Setting winnt_mpm_state to AP_MPMQ_STOPPING in child main should be sufficient unless I am missing something. the code in service.c which shuts down the serve

[PATCH 1.3] work around some annoyances with ab error handling

(or consider this a bitch at the mess we call ab; just cleaning out some of my source trees of potentially useful changes) if errno != 0, err() prints the errno string... yet err() is called sometimes when errno is irrelevant; large-scale rework of error handling would be nice, but this at lea

Re: cvs commit: httpd-2.0/server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h

Bill Stoddard wrote: Do you know of any cases that actually require mpm_state to be updated in ap_signal_parent()? Setting winnt_mpm_state to AP_MPMQ_STOPPING in child main should be sufficient unless I am missing something. the code in service.c which shuts down the server for other reasons? A

Re: httpd-2.1 segfaults at startup

On Tue, Jan 13, 2004 at 06:31:18PM -0600, Art Haas wrote: > I've been building and using what will be httpd-2.1 for months. Just > within the last week or two, my builds have all failed when I try to run > them. As others are certainly running the CVS head builds without > problems, I'm hoping for