Fwd: cvs commit: httpd-dist Announcement2.html Announcement2.txt
Announcement to go out tommorow, after the mirrors have caught up. Thanks all, glad to hear the success stories, and hopefully we will have a cleaner binbuild script to work from this coming 2.0.46 release :-) Bill >wrowe 2003/03/31 23:40:19 > > Modified:.Announcement2.html Announcement2.txt > Log: >Very short list of bug fixes/new features. This isn't supposed to be >a copy of changes - just (very visible) highlights. > > Revision ChangesPath > 1.34 +38 -2 httpd-dist/Announcement2.html > > Index: Announcement2.html > === > RCS file: /home/cvs/httpd-dist/Announcement2.html,v > retrieving revision 1.33 > retrieving revision 1.34 > diff -u -r1.33 -r1.34 > --- Announcement2.html1 Apr 2003 03:27:08 - 1.33 > +++ Announcement2.html1 Apr 2003 07:40:19 - 1.34 > @@ -114,10 +114,46 @@ > [Christian Kratzer <[EMAIL PROTECTED]>, Bjoern A. Zeeb <[EMAIL > PROTECTED]>] > > > -Bugs fixed since Apache 2.0.44 > +Bugs fixed and features added since Apache 2.0.44 > > -... > +Prevent endless loops of internal redirects in mod_rewrite by > +aborting after exceeding a limit of internal redirects. The > +limit defaults to 10 and can be changed using the RewriteOptions > +directive. PR 17462. > > +Configurable compression level for mod_deflate. > + > +Allow SSLMutex to select/use the full range of APR locking > +mechanisms available to it (e.g. same choices as AcceptMutex.) > + > +mod_cgi, mod_cgid, mod_ext_filter: Log errors when scripts cannot > +be started on Unix because of such problems as bad permissions, > +bad shebang line, etc. > + > +Try to log an error if a piped log program fails and try to > +restart a piped log program in more failure situations. > + > +Added support for mod_auth_LDAP, with a new AuthLDAPCharsetConfig > +directive, to convert extended characters in the user ID to UTF-8, > +before authenticating against the LDAP directory. > + > +No longer removes the Content-Length from responses via mod_proxy. > + > +Enhance mod_isapi's WriteClient() callback to provide better emulation > +for isapi extensions that use the first WriteClient() to send status > +and headers, such as the foxisapi module. > + > +Win32: Avoid busy wait (consuming all the CPU idle cycles) when > +all worker threads are busy. > + > +Introduced .pdb debugging symbols for Win32 release builds. > + > +Fixed piped access logs on Win32. > + > +Fix path handling of mod_rewrite, especially on non-unix systems. > +There was some confusion between local paths and URL paths. > + > +Added an rpm build script. > > > >
rfc: new API to traverse filter chains
in mod_perl 2.0 we register only four filter names (in:out:req:conn) and then
we install the actuall perl callbacks using one of these four filter names and
storing the actual filter's callback information in f->ctx. If later on we
want to do something with an inserted filter we have no API to find it, since
it's not identified by name, but the data inside f->ctx. Therefore we need a
new API to traverse the filter chain and find what we want using a custom
callback.
Here is the API and implementation that I came up with (it needs the docco and
the standard DECLARE stuff, which I ask to disregard for now and concentrate
on the API/implementation itself; once it's polished I'll post a complete patch).
The function that I'm requesting to add is somewhat similar to apr_table_do.
typedef int (ap_filter_chain_traverse_fh_t)(void *data, ap_filter_t *f);
int ap_filter_chain_traverse(ap_filter_chain_traverse_fh_t *traverse,
void *data, ap_filter_t **chain);
int ap_filter_chain_traverse(ap_filter_chain_traverse_fh_t *traverse,
void *data, ap_filter_t **chain)
{
int rv = 0;
ap_filter_t *curr = *chain;
while (curr) {
if ((rv = (*traverse)(data, curr)) != 0) {
return rv;
}
curr = curr->next;
}
return rv;
}
I'm not sure regarding the chain argument. Looking at the util_filter.c, it
looks in proto_ and normal chain. Could there be a problem on the caller side?
Won't it be enough to use one of r->output_filters, c->output_filters,
r->input_filters, c->input_filters if all I care is the custom filters?
Here is an example of usage by mod_perl 2.0. This is an implementation of a
function that will remove a filter by its perl handler name, e.g.:
$r->remove_output_filter("TestHandler::out_filter");
there is a wrapper that translates this perl-side call to C's
modperl_filter_remove_by_handler_name().
typedef struct {
char* filter_name;
char* handler_name;
ap_filter_t* f;
} filter_chain_traverse_t;
static int find_filter_by_handler_name(void *data, ap_filter_t *f)
{
apr_pool_t* p = f->r ? f->r->pool : f->c->pool;
filter_chain_traverse_t* traverse = (filter_chain_traverse_t*)data;
char *normalized_name;
/* 'name' in frec is always lowercased */
normalized_name = apr_pstrdup(p, traverse->filter_name);
ap_str_tolower(normalized_name);
/* skip non-mod_perl filters */
if (strNE(f->frec->name, normalized_name)) {
return 0;
} else {
modperl_filter_ctx_t *ctx = f->ctx;
if (strEQ(ctx->handler->name, traverse->handler_name)) {
traverse->f = f;
return 1; /* found what we wanted */
}
}
return 0;
}
/* modperl_filter_remove_by_handler_name(aTHX_ r, c,
*MP_OUTPUT_FILTER_MODE,
*"MyFilter::output_lc")
*/
void modperl_filter_remove_by_handler_name(pTHX_ request_rec *r,
conn_rec *c,
modperl_filter_mode_e mode,
char* handler_name)
{
int rv = 0;
apr_pool_t *pool = r ? r->pool : c->pool;
ap_filter_t *f;
filter_chain_traverse_t *traverse =
apr_pcalloc(pool, sizeof(filter_chain_traverse_t*));
/* XXX: generalize for conn/req in/out */
traverse->filter_name = MP_FILTER_REQUEST_OUTPUT_NAME;
traverse->handler_name = handler_name;
rv = ap_filter_chain_traverse(find_filter_by_handler_name, traverse,
&r->output_filters); /* XXX: generalize */
if (rv) {
f = traverse->f; /* XXX: validate */
MP_TRACE_f(MP_FUNC, "found filter handler %s\n", handler_name);
}
else {
Perl_croak(aTHX_ "unable to find filter handler '%s'\n", handler_name);
}
MP_TRACE_f(MP_FUNC, "removing filter %s\n", handler_name);
if (mode == MP_INPUT_FILTER_MODE) {
ap_remove_input_filter(f);
}
else {
ap_remove_output_filter(f);
}
}
__
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: Apache 2.0.45 -alpha tarball candidates for testing
--On Monday, March 31, 2003 7:57 PM -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: layouts (and thus the Apache binbuild mechanism) have some problems... can anybody get it to work? FreeBSD 5.0: unpack the alpha then $ cd httpd-2.0.45 $ build/binbuild.sh ... APR Version: 0.9.3 ** Error: unable to find layout Apache configure failed for srclib/apr ... The error message is correct. APR doesn't have the layout called "Apache" - I don't think it ever has. I think prior versions silently ignored this condition and just punted - which actually might have worked... The workaround is to either use a layout that all of them share, or manually expand the layout (via the configure options). The real fix is to drop the layout option before we do the subdir configure invocations in APR_SUBDIR_CONFIG (untested, but sort of based on how autoconf drops --no-create/--no-recursion): ap_configure_args= ap_sep= for ac_configure_arg in $ac_configure_args do case "$ac_configure_arg" in --enable-layout=*) continue ;; esac ap_configure_args="$ap_configure_args$ap_sep'$ac_configure_arg'" ap_sep=" " done ap_configure_args would be used instead of ac_configure_args in the subdir configure invocation. And, the way that APR_SUBDIR_CONFIG is called within httpd's configure.in should allow the layout-expanded options to still be passed. -- justin
Re: Apache 2.0.45 -alpha tarball candidates for testing
William A. Rowe, Jr. wrote: The release tarball (and win32 .zip file) are now available for testing from; http://httpd.apache.org/dev/dist/ layouts (and thus the Apache binbuild mechanism) have some problems... can anybody get it to work? FreeBSD 5.0: unpack the alpha then $ cd httpd-2.0.45 $ build/binbuild.sh ... APR Version: 0.9.3 ** Error: unable to find layout Apache configure failed for srclib/apr ... RH 6.2: same error
Re: mixing c & c++ on HP-UX
hi bill, thanks for your help. that doesn't seem to be the root cause. we've been loading our modules without BIND_NOSTART for a while now on HP-UX. the program is dumping core in apr_pools.c:1976 with a SIGSEGV. i'm gonna start digging deeper, cheers, andy William A. Rowe, Jr. wrote: Andy, there were new fixes in 2.0.45 that should address this. See... http://cvs.apache.org/viewcvs.cgi/apr/dso/unix/dso.c Bill At 04:57 PM 3/31/2003, Andy Cutright wrote: hi all, there was some discussion on this list about HP-UX and c++ modules. we had a mixture like this running with 2.0.43. we've recently upgraded to 2.0.44, and we're now experiencing problems at load time. i'm wondering if anyone is running 2.0.44 on HP-UX with c++ modules successfully, cheers, andy
Re: Apache 2.0.45 -alpha tarball candidates for testing
> www.apache.org server, but we need a variety of platforms and different > configurations to have complete confidence in the release. My Powerbook: Darwin monalisa.sfo.covalent.net 6.4 Darwin Kernel Version 6.4: Wed Jan 29 18:50:42 PST 2003; root:xnu/xnu-344.26.obj~1/RELEASE_PPC Power Macintosh powerpc With gcc: [EMAIL PROTECTED] httpd-2.0.45 $ cc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs Thread model: posix Apple Computer, Inc. GCC version 1173, based on gcc version 3.1 20020420 (prerelease) unpacks, builds with bundled libtool and runs the perl-framework against both worker and prefork. The only test that fails is that ssl/http one that gives us a response without headers. We know about that. My +1 (all +2 cents worth) for release. S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 856 4214 303 Second Street #375 South Fax: (415) 856 4210 San Francisco CA 94107 PGP Fingerprint: 7A8D B189 E871 80CB 9521 9320 C11E 7B47 964F 31D9
Re: httpd 2.0.45-alpha on Solaris 9 w/Sun C 5.5 EA2 2003/01/09
Spinka, Kristofer wrote: Builds and runs wonderfully on x86 and SPARC. I have not had the time for extensive testing, but just some simple feedback. Notes: -- I removed "-mt" from pthreads_cflags. in case you don't watch the commit logs, your change to apr_thread.m4 was just committed... thanks so much for your help!
Re: httpd 2.0.45-alpha on Solaris 9 w/Sun C 5.5 EA2 2003/01/09
Just to confirm, here is a SPARC version of that ldd with "-mt" removed: [EMAIL PROTECTED]:~/src/httpd-2.0.45] ldd .libs/httpd libz.so => /usr/local/lib/libz.so libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0 libexpat.so.0 => /usr/local/lib/libexpat.so.0 libapr-0.so.0 => /usr/local/apache2/lib/libapr-0.so.0 libsendfile.so.1 => /usr/lib/libsendfile.so.1 librt.so.1 =>/usr/lib/librt.so.1 libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libthread.so.1 =>/usr/lib/libthread.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 /kristofer On Mon, 31 Mar 2003, Jeff Trawick wrote: > Spinka, Kristofer wrote: > >>any idea why you get libpthread linked without hacking anything to refer > >>to libpthread directly, but I don't? > > > > > > Did you remove the "-mt" from srclib/apr/configure / > > srclib/apr/apr_threads.m4? > > I'm in the middle of trying that, but I'm far enough along that I can > see that it works now :) > > I don't see any indication that "-mt" in apr_threads.m4 works with > anything but Solaris cc > > http://cvs.apache.org/viewcvs.cgi/apr/Attic/threads.m4.diff?r1=1.9&r2=1.10&diff_format=h > > that doesn't mean that some other unknown compiler on an obscure > platform isn't relying on that code, but we're just going to have to > find out :) > > (i.e., delete the -mt check, which allows configure to discover the need > for -lpthread) > > Thanks, > > Jeff > > > >
Re: httpd 2.0.45-alpha on Solaris 9 w/Sun C 5.5 EA2 2003/01/09
Spinka, Kristofer wrote: any idea why you get libpthread linked without hacking anything to refer to libpthread directly, but I don't? Did you remove the "-mt" from srclib/apr/configure / srclib/apr/apr_threads.m4? I'm in the middle of trying that, but I'm far enough along that I can see that it works now :) I don't see any indication that "-mt" in apr_threads.m4 works with anything but Solaris cc http://cvs.apache.org/viewcvs.cgi/apr/Attic/threads.m4.diff?r1=1.9&r2=1.10&diff_format=h that doesn't mean that some other unknown compiler on an obscure platform isn't relying on that code, but we're just going to have to find out :) (i.e., delete the -mt check, which allows configure to discover the need for -lpthread) Thanks, Jeff
Re: httpd 2.0.45-alpha on Solaris 9 w/Sun C 5.5 EA2 2003/01/09
> any idea why you get libpthread linked without hacking anything to refer > to libpthread directly, but I don't? Did you remove the "-mt" from srclib/apr/configure / srclib/apr/apr_threads.m4? /kristofer
Re: mixing c & c++ on HP-UX
Andy, there were new fixes in 2.0.45 that should address this. See... http://cvs.apache.org/viewcvs.cgi/apr/dso/unix/dso.c Bill At 04:57 PM 3/31/2003, Andy Cutright wrote: >hi all, > >there was some discussion on this list about HP-UX and c++ modules. we had a mixture >like this running with 2.0.43. we've recently upgraded to 2.0.44, and we're now >experiencing problems at load time. i'm wondering if anyone is running 2.0.44 on >HP-UX with c++ modules successfully, > >cheers, >andy
Re: httpd 2.0.45-alpha on Solaris 9 w/Sun C 5.5 EA2 2003/01/09
Spinka, Kristofer wrote: Configure Used: --- CC=cc CFLAGS=-xO5 ./configure --with-mpm=worker --enable-rewrite --enable-so --enable-headers --enable-deflate Compiler Version: - Sun ONE Studio 8 Compilers (Beta) Sun C 5.5 EA2 2003/01/09 Proper libpthread.so Linking: any idea why you get libpthread linked without hacking anything to refer to libpthread directly, but I don't? - [EMAIL PROTECTED]:/usr/local/apache2/bin] ldd ./httpd libz.so.1 => /usr/lib/libz.so.1 libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0 libexpat.so.0 => /usr/local/apache2/lib/libexpat.so.0 libapr-0.so.0 => /usr/local/apache2/lib/libapr-0.so.0 libsendfile.so.1 => /usr/lib/libsendfile.so.1 librt.so.1 =>/usr/lib/librt.so.1 libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libc.so.1 => /usr/lib/libc.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libthread.so.1 =>/usr/lib/libthread.so.1 $ ldd .libs/httpd libaprutil-0.so.0 => /export/home/trawick/apacheinst/lib/libaprutil-0.so.0 libexpat.so.0 => /export/home/trawick/apacheinst/lib/libexpat.so.0 libapr-0.so.0 => /export/home/trawick/apacheinst/lib/libapr-0.so.0 librt.so.1 =>/usr/lib/librt.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libdl.so.1 =>/usr/lib/libdl.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
Re: how do you debug a module from dev studio?
At 04:14 PM 3/31/2003, Jeff D. Hamann wrote: >I'm desparately wanting to develop a new module for apache2 (that doesn't >lots of computations) and have no idea how you go about debugging a module >using devstudio. How do you debug a module using devstudio? Couple of quick tricks. First, it's easier now that we copy the .pdb files along with the modules and binaries (even for release builds.) You have alot more flexibility. Second, if you are building debug modules, you should plug them into a debug build of the server. There are some oddities in malloc()/free() between the two build types. To build the server in devstudio, just open the apache.dsw project and build the InstallBin target. Set up the debug settings to point to the \apache2\bin\apache.exe program and set the arguments to -X. That will tell apache not to launch a child process, but run in the one process. Add your module to the list of .dll's to preload. Now you can set up breakpoints in apache, within your own module, etc. Hope this helps. Bill
mixing c & c++ on HP-UX
hi all, there was some discussion on this list about HP-UX and c++ modules. we had a mixture like this running with 2.0.43. we've recently upgraded to 2.0.44, and we're now experiencing problems at load time. i'm wondering if anyone is running 2.0.44 on HP-UX with c++ modules successfully, cheers, andy
httpd 2.0.45-alpha on Solaris 9 w/Sun C 5.5 EA2 2003/01/09
Builds and runs wonderfully on x86 and SPARC. I have not had the time for extensive testing, but just some simple feedback. Notes: -- I removed "-mt" from pthreads_cflags. Configure Used: --- CC=cc CFLAGS=-xO5 ./configure --with-mpm=worker --enable-rewrite --enable-so --enable-headers --enable-deflate Compiler Version: - Sun ONE Studio 8 Compilers (Beta) Sun C 5.5 EA2 2003/01/09 Proper libpthread.so Linking: - [EMAIL PROTECTED]:/usr/local/apache2/bin] ldd ./httpd libz.so.1 => /usr/lib/libz.so.1 libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0 libexpat.so.0 => /usr/local/apache2/lib/libexpat.so.0 libapr-0.so.0 => /usr/local/apache2/lib/libapr-0.so.0 libsendfile.so.1 => /usr/lib/libsendfile.so.1 librt.so.1 =>/usr/lib/librt.so.1 libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libc.so.1 => /usr/lib/libc.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libthread.so.1 =>/usr/lib/libthread.so.1 /kristofer
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread?
--On Monday, March 31, 2003 14:59:17 -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: I'm using Sun WorkShop 5.0 sometimes, and these builds result in executables like httpd referencing libthread but not libpthread. We pass cc the -mt switch, but at least with this version that switch isn't enough to pull in libpthread. Can anybody confirm that with a more recent Sun compiler APR apps are getting libpthread? Can you please send the relevant config for mod_ext_filter? I know that WS 5.0 is *really* out-of-date. You also need to make sure that you've applied all of the 5.x updates (as well as OS updates). ISTR we had problems before with 5.0 that disappeared when we applied all of the patches for both the OS and compiler/linker. I believe that the -lpthread doesn't matter due to the way Solaris's thread libraries are implemented. It'd map to the same function call. -- justin
Re: mod_deflate -- File size lower bound needed?
FYI: There was a serious brain fart (mine) in the previous message... I said... >> 2. If there's no EOS in the brigade yet you have to assume >> more is coming so now it's nut-crackin' time. If the 'minimum >> file size' is less than the amount of data already in the first >> brigade showing up then it's also a no brainer... just pass >> it on without compressing. If the minimum file size is >> larger than what's in the first brigade... then it's time to >> start buffering ( if the code allows it ). What I meant was that if the 'minimum_file_size' is less than the amount of data already in the first brigade that shows up then you already know that this puppy is NOT 'below the minimum' and ( based on other criteria ) is eligible for compression. At this point it's is a sure-fire 'MAY' be compressed depending on other eligibilty checks.
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread? (fwd)
Spinka, Kristofer wrote: Can we take the -mt flag out of the works? that makes sense to me based on the doc
how do you debug a module from dev studio?
I'm desparately wanting to develop a new module for apache2 (that doesn't lots of computations) and have no idea how you go about debugging a module using devstudio. How do you debug a module using devstudio? Jeff.
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread? (fwd)
Can we take the -mt flag out of the works? /kristofer On Mon, 31 Mar 2003, Jeff Trawick wrote: > Spinka, Kristofer wrote: > > 1. Clarification: -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT should be > > specified explicitly. During linking, -lpthread should be specified explictly. > > existing code does that via apr_hints.m4 > > I'm testing some changes to apr_hints.m4 now that will make sure > -lpthread is specified explicitly. > > Thanks, > > Jeff > >
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread?
Justin Erenkrantz wrote: --On Monday, March 31, 2003 14:59:17 -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: I'm using Sun WorkShop 5.0 sometimes, and these builds result in executables like httpd referencing libthread but not libpthread. We pass cc the -mt switch, but at least with this version that switch isn't enough to pull in libpthread. Can anybody confirm that with a more recent Sun compiler APR apps are getting libpthread? Can you please send the relevant config for mod_ext_filter? here is a simplified version: ExtFilterDefine traceplain \ cmd="/usr/bin/tee /tmp/traceplain" setoutputfilter traceplain;deflate testing with an httpd that didn't link to libpthread (but did link to libthread) showed the problem I'm about to get a build that links to libpthread and I'll try to reproduce
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread? (fwd)
Spinka, Kristofer wrote: 1. Clarification: -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT should be specified explicitly. During linking, -lpthread should be specified explictly. existing code does that via apr_hints.m4 I'm testing some changes to apr_hints.m4 now that will make sure -lpthread is specified explicitly. Thanks, Jeff
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread? (fwd)
1. Clarification: -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT should be specified explicitly. During linking, -lpthread should be specified explictly. /kristofer On Mon, 31 Mar 2003, Spinka, Kristofer wrote: > 1. It's an out of date, and Solaris-biased (as opposed to POISX), man > page. Even on Solaris 9. > > > http://docs.sun.com/source/816-2454/cc_ops.app.html#pgfId-25 > > A.3.42 -mt > Macro option that expands to -D_REENTRANT -lthread. If you are doing your > own multithread coding, you must use this option in the compile and link > steps. To obtain faster execution, this option requires a multiprocessor > system. On a single-processor system, the resulting executable usually > runs more slowly with this option. > > > 2. _POSIX_C_SOURCE=199506L tells the compiler to use POSIX.1c interfaces > as opposed to Solaris (or other) interfaces for symbols that might have the > same name. I suppose apr/httpd could get by with just > _POSIX_PTHREAD_SEMANTICS, to take care of the threads, but I think it > would be a benefit to be sure that the correct (POISX) sections of the > Solaris header files are being processed. > >/kristofer > > On Mon, 31 Mar 2003, Jeff Trawick wrote: > > > Spinka, Kristofer wrote: > > > To be sure that the compiler is respecting the POSIX behavior, remove > > > the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread. > > > > "man pthread_create" says "cc -mt foo.c -lpthread" > > > > _POSIX_C_SOURCE=199506L sounds like something to force my program to use > > only those interfaces described in some particular document... we want > > access to everything the platform offers > > > > > > >
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread?
--On Monday, March 31, 2003 14:59:17 -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: I'm using Sun WorkShop 5.0 sometimes, and these builds result in executables like httpd referencing libthread but not libpthread. We pass cc the -mt switch, but at least with this version that switch isn't enough to pull in libpthread. Can anybody confirm that with a more recent Sun compiler APR apps are getting libpthread? Can you please send the relevant config for mod_ext_filter? I know that WS 5.0 is *really* out-of-date. You also need to make sure that you've applied all of the 5.x updates (as well as OS updates). ISTR we had problems before with 5.0 that disappeared when we applied all of the patches for both the OS and compiler/linker. I believe that the -lpthread doesn't matter due to the way Solaris's thread libraries are implemented. It'd map to the same function call. -- justin
RE: Apache 2.0.45 -alpha tarball candidates for testing
Is there any way of telling libtool to NOT use gcc/cc for linking. Instead, use "ld" ?. libtool 1.4.3 seems to have problems on HP-UX. When I use 1.4, everything seems to work just fine. --Madhu >-Original Message- >From: Thom May [mailto:[EMAIL PROTECTED] >Sent: Monday, March 31, 2003 1:00 PM >To: [EMAIL PROTECTED] >Subject: Re: Apache 2.0.45 -alpha tarball candidates for testing > > >* William A. Rowe, Jr. ([EMAIL PROTECTED]) wrote : >> The release tarball (and win32 .zip file) are now available >for testing from; >> >> http://httpd.apache.org/dev/dist/ >> >> Please test this 2.0.45-alpha candidate for general release >within the >> next 24 hours. Once the dev@ list receives enough positive feedback, >> we will release the files to general availability, moving >them to their usual >> locations. This code has been in place for several days on >the primary >> www.apache.org server, but we need a variety of platforms >and different >> configurations to have complete confidence in the release. >> > >looks good on OS X (worker with everything as DSO), and linux >in the brief >seconds i had to check that box... >+1 >-Thom >
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread?
On 31/3/03 20:59, "Jeff Trawick" <[EMAIL PROTECTED]> wrote: > I'm using Sun WorkShop 5.0 sometimes, and these builds result in > executables like httpd referencing libthread but not libpthread. > We pass cc the -mt switch, but at least with this version that switch > isn't enough to pull in libpthread. Can anybody confirm that with a > more recent Sun compiler APR apps are getting libpthread? > > This apparently results in apr_proc_create() forking more than just the > calling thread, and you can get anoying stuff like this when running > Apache's mod_ext_filter with the worker MPM: > > [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept: > (client socket) > > (By the time the fork()-ed child of the calling thread got around to > exec()-ing the external filter program, the copy of the listener thread > in the forked() child reached the accept() call.) > > There was other undiagnosed havoc going on, including a child process > exiting with a fatal error code which led to the parent bailing out with > a large number of children left to clean up manually. This was probably > the neatest failure: > > ibthread panic: fault in libthread critical section : dumping core (PID: > 4894 LWP 12) > stacktrace: >ff0faaa8 >ff0fa8fc >ff103498 >ff0ff8f0 >ff105558 >ff2d2bac >36964 >ff2d29bc >ff10b728 >ff2d2978 > > Cool, huh? > > I haven't gotten to the point of teaching APR to pull in libpthread in > this situation and rebuilding Apache's httpd and retesting, but I > thought I'd put this out there to see if somebody with a newer compiler > is getting better results. Jeff/all... We got Forte on Nagoya, thanks to the freaks @ Sun! :-) /opt/forte/ Pier
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread? (fwd)
1. It's an out of date, and Solaris-biased (as opposed to POISX), man page. Even on Solaris 9. http://docs.sun.com/source/816-2454/cc_ops.app.html#pgfId-25 A.3.42 -mt Macro option that expands to -D_REENTRANT -lthread. If you are doing your own multithread coding, you must use this option in the compile and link steps. To obtain faster execution, this option requires a multiprocessor system. On a single-processor system, the resulting executable usually runs more slowly with this option. 2. _POSIX_C_SOURCE=199506L tells the compiler to use POSIX.1c interfaces as opposed to Solaris (or other) interfaces for symbols that might have the same name. I suppose apr/httpd could get by with just _POSIX_PTHREAD_SEMANTICS, to take care of the threads, but I think it would be a benefit to be sure that the correct (POISX) sections of the Solaris header files are being processed. /kristofer On Mon, 31 Mar 2003, Jeff Trawick wrote: > Spinka, Kristofer wrote: > > To be sure that the compiler is respecting the POSIX behavior, remove > > the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread. > > "man pthread_create" says "cc -mt foo.c -lpthread" > > _POSIX_C_SOURCE=199506L sounds like something to force my program to use > only those interfaces described in some particular document... we want > access to everything the platform offers > >
Re: Apache 2.0.45 -alpha tarball candidates for testing
* William A. Rowe, Jr. ([EMAIL PROTECTED]) wrote : > The release tarball (and win32 .zip file) are now available for testing from; > > http://httpd.apache.org/dev/dist/ > > Please test this 2.0.45-alpha candidate for general release within the > next 24 hours. Once the dev@ list receives enough positive feedback, > we will release the files to general availability, moving them to their usual > locations. This code has been in place for several days on the primary > www.apache.org server, but we need a variety of platforms and different > configurations to have complete confidence in the release. > looks good on OS X (worker with everything as DSO), and linux in the brief seconds i had to check that box... +1 -Thom
Re: anybody using Sun's compiler and getting libthread referencedby executables but not libpthread?
The -mt compiler option only instructs the C++ compiler to perform some multithread safe checks and preserve a specific linking order with the Solaris thread library. On Solaris, the POSIX thread library is an abtraction of Sun's native thread support. So any application that wishes to use this abstraction should link first with libpthread.so (POSIX), which implicitly links libthread.so (Solaris). In reality they all call lwp_create(), but the parameters, limits, etc. are specific to the abstracted interface. To be sure that the compiler is respecting the POSIX behavior, remove the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread. There is in fact a mixed mode identifier, but I don't think it is necessary here. /kristofer On Mon, 31 Mar 2003, Jeff Trawick wrote: > I'm using Sun WorkShop 5.0 sometimes, and these builds result in > executables like httpd referencing libthread but not libpthread. > We pass cc the -mt switch, but at least with this version that switch > isn't enough to pull in libpthread. Can anybody confirm that with a > more recent Sun compiler APR apps are getting libpthread? > > This apparently results in apr_proc_create() forking more than just the > calling thread, and you can get anoying stuff like this when running > Apache's mod_ext_filter with the worker MPM: > > [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept: > (client socket) > > (By the time the fork()-ed child of the calling thread got around to > exec()-ing the external filter program, the copy of the listener thread > in the forked() child reached the accept() call.) > > There was other undiagnosed havoc going on, including a child process > exiting with a fatal error code which led to the parent bailing out with > a large number of children left to clean up manually. This was probably > the neatest failure: > > ibthread panic: fault in libthread critical section : dumping core (PID: > 4894 LWP 12) > stacktrace: > ff0faaa8 > ff0fa8fc > ff103498 > ff0ff8f0 > ff105558 > ff2d2bac > 36964 > ff2d29bc > ff10b728 > ff2d2978 > > Cool, huh? > > I haven't gotten to the point of teaching APR to pull in libpthread in > this situation and rebuilding Apache's httpd and retesting, but I > thought I'd put this out there to see if somebody with a newer compiler > is getting better results. > >
anybody using Sun's compiler and getting libthread referenced byexecutables but not libpthread?
I'm using Sun WorkShop 5.0 sometimes, and these builds result in executables like httpd referencing libthread but not libpthread. We pass cc the -mt switch, but at least with this version that switch isn't enough to pull in libpthread. Can anybody confirm that with a more recent Sun compiler APR apps are getting libpthread? This apparently results in apr_proc_create() forking more than just the calling thread, and you can get anoying stuff like this when running Apache's mod_ext_filter with the worker MPM: [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept: (client socket) (By the time the fork()-ed child of the calling thread got around to exec()-ing the external filter program, the copy of the listener thread in the forked() child reached the accept() call.) There was other undiagnosed havoc going on, including a child process exiting with a fatal error code which led to the parent bailing out with a large number of children left to clean up manually. This was probably the neatest failure: ibthread panic: fault in libthread critical section : dumping core (PID: 4894 LWP 12) stacktrace: ff0faaa8 ff0fa8fc ff103498 ff0ff8f0 ff105558 ff2d2bac 36964 ff2d29bc ff10b728 ff2d2978 Cool, huh? I haven't gotten to the point of teaching APR to pull in libpthread in this situation and rebuilding Apache's httpd and retesting, but I thought I'd put this out there to see if somebody with a newer compiler is getting better results.
Apache not picking up CC from APR?
HEAD of everything, Solaris, out-of-tree APR and apr-util Apache picks up CFLAGS from APR, but not CC, resulting in a failure if CFLAGS has non-gcc options but gcc is found
Re: Apache 2.0.45 -alpha tarball candidates for testing
Works fine under NT 4.0 with ssl and mod_jk since ~10 hours so far. André >>> [EMAIL PROTECTED] 31.03.2003 19:31:37 >>> Works just dandy under Solaris 8, prefork and worker, with SSL enabled. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: mod_deflate -- File size lower bound needed?
> [EMAIL PROTECTED] writes: > >> Stephen Pierzchala wrote: >> >> All: >> >> A question for discussion: should a lower bound be set in mod_deflate? >> >> I just ran a test using the Linux Documentation Project files and found >> that some of the files in the test group were quite small, less that 100 >> bytes. When mod_deflate tackled these files, I saw a file sized increase >> of between 12 and 15 bytes. >> >> Doesn't sound like a lot, until maybe you start to add up all of those >> HTML error pages we all send. >> >> I open the floor to debate. :-) > > > while this may be easy for the cases where the filter gets passed a > content-length header, No brainer ( if it's accurate when the filter fires up ). > it may be harder for the ones where it doesn't > know the size of the page before it starts compressing.. Any filter is supposed to be able to buffer data. Harder, yes, but not impossible. The whole filtering scheme is SUPPOSED to be able to handle this, no problems. Not sure if anything has actually exercised this yet, though. Might be time to see if it really works. The 'cheap trick' compromise would be to realize that by the time the first brigade shows up there will probably be only one of 2 scenarios... 1. The response is less than the size of the fileread and/or CGI transfer buffer size ( 4k? ) and nothing else is coming ( There is already an EOS in the first brigade. This can be treated the same as having 'content-length' because you know for sure how long the full response is before you have to decide whether to fire up the compression. 2. If there's no EOS in the brigade yet you have to assume more is coming so now it's nut-crackin' time. If the 'minimum file size' is less than the amount of data already in the first brigade showing up then it's also a no brainer... just pass it on without compressing. If the minimum file size is larger than what's in the first brigade... then it's time to start buffering ( if the code allows it ). I would say that just allowing a 'minimum file size' in the 2-3k byterange and only doing the check on the first brigade would handle most situations where anyone is worried about whether something is worth compression. Anything over about 900 bytes is almost ALWAYS going to show some size reduction. Problem solved. If someone wants to start setting a minimum file size of 100,000 bytes then I would suggest the 'requirement' on their end be that all responses MUST have 'Content-Length:' from the origin ( if it's not a file read ) until mod_deflate can actually 'store and forward' any size response. > I'm cool with putting in a directive, but not sure how to write the doc's up > to say that this is a 'guidance' only and that it might be ignored. See above. Limit it to the normal (Apache) I/O buffer read size(s) and suggest that anything above that can/should have 'Content-Length' or it's not eligible for the 'minimum size' check. > we should also put in a directive to only compress when system load is > below a certain level. (but we would need a apr_get_system_load() > function first .. any volunteers? ) If you go down this route watch out for what's called 'back-flash'. You can easily get into a catch-22 at the 'threshhold' rate where you are ping-ponging over/under the threshhold because currently executing ZLIB compressions will always be included in the 'system load' stat you are computing. In other words... if you don't want to compress because you think the machine is too busy then it might only be too busy because it's already compressing. The minute you turn off compression you drop under-threshhold and now you are 'thrashing' and 'ping-ponging' over/under the threshhold. You might want to always compare system load against transaction/compression task load to see if something other than normal compression activity is eating the CPU. Low transaction count + high CPU load = Something other than compression is eating the CPU and stopping compressions won't really make much difference. High transaction count + high CPU load + high number of compressions in progress = Might be best to back off on the compressions for a moment. [EMAIL PROTECTED]
Re: Apache 2.0.45 -alpha tarball candidates for testing
Works just dandy under Solaris 8, prefork and worker, with SSL enabled. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: mod_deflate -- File size lower bound needed?
Stephen Pierzchala wrote: All: A question for discussion: should a lower bound be set in mod_deflate? I just ran a test using the Linux Documentation Project files and found that some of the files in the test group were quite small, less that 100 bytes. When mod_deflate tackled these files, I saw a file sized increase of between 12 and 15 bytes. Doesn't sound like a lot, until maybe you start to add up all of those HTML error pages we all send. I open the floor to debate. :-) smp while this may be easy for the cases where the filter gets passed a content-length header, it may be harder for the ones where it doesn't know the size of the page before it starts compressing.. I'm cool with putting in a directive, but not sure how to write the doc's up to say that this is a 'guidance' only and that it might be ignored. we should also put in a directive to only compress when system load is below a certain level. (but we would need a apr_get_system_load() function first .. any volunteers? )
Re: Apache 2.0.45 -alpha tarball candidates for testing
So far the testing on NetWare has been good. Everything seems to build and run as expected. We are continuing with our testing to make sure that there are no surprises. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Monday, March 31, 2003 12:56:29 AM >>> The release tarball (and win32 .zip file) are now available for testing from; http://httpd.apache.org/dev/dist/ Please test this 2.0.45-alpha candidate for general release within the next 24 hours. Once the dev@ list receives enough positive feedback, we will release the files to general availability, moving them to their usual locations. This code has been in place for several days on the primary www.apache.org server, but we need a variety of platforms and different configurations to have complete confidence in the release. Thank you in advance for participating in the testing, and thanks to both Brian Pane and Justin Erenkrantz who helped roll these out. Bill
mod_deflate -- File size lower bound needed?
All: A question for discussion: should a lower bound be set in mod_deflate? I just ran a test using the Linux Documentation Project files and found that some of the files in the test group were quite small, less that 100 bytes. When mod_deflate tackled these files, I saw a file sized increase of between 12 and 15 bytes. Doesn't sound like a lot, until maybe you start to add up all of those HTML error pages we all send. I open the floor to debate. :-) smp
Re: Apache 2.0.45 -alpha tarball candidates for testing
On Mon, 2003-03-31 at 00:38, Justin Erenkrantz wrote: > --On Monday, March 31, 2003 1:56 AM -0600 "William A. Rowe, Jr." > <[EMAIL PROTECTED]> wrote: > > > Please test this 2.0.45-alpha candidate for general release within the > > next 24 hours. Once the dev@ list receives enough positive feedback, > > we will release the files to general availability, moving them to their > > Builds, passes httpd-test (modulo my recent commit to httpd-test), and serves > pages on Solaris 9 (with .44 modules). +1. -- justin Tested successfully with worker MPM on Linux. +1 Brian
Re: [patch] two small problems in ssl_engine_mutex.c
William A. Rowe, Jr. wrote:
>
> One, win32 won't compile (nor any platform missing chown). In this
> case we didn't need it and have a good macro to look at.
+1. We also use chown in a few other places as well:
./modules/generators/mod_cgid.c:if (chown(sconf->sockname,
unixd_config.user_id, -1) < 0) {
./modules/ssl/ssl_scache_dbm.c:chown(mc->szSessionCacheDataFile,
unixd_config.user_id, -1 /* no gid change */);
./modules/ssl/ssl_scache_dbm.c:if (chown(apr_pstrcat(p,
mc->szSessionCacheDataFile, SSL_DBM_FILE_SUFFIX_DIR, NULL),
./modules/ssl/ssl_scache_dbm.c:if (chown(apr_pstrcat(p,
mc->szSessionCacheDataFile, ".db", NULL),
./modules/ssl/ssl_scache_dbm.c:chown(apr_pstrcat(p,
mc->szSessionCacheDataFile, ".dir", NULL),
./modules/ssl/ssl_scache_dbm.c:if (chown(apr_pstrcat(p,
mc->szSessionCacheDataFile, SSL_DBM_FILE_SUFFIX_PAG, NULL),
./modules/ssl/ssl_scache_dbm.c:if (chown(apr_pstrcat(p,
mc->szSessionCacheDataFile, ".db", NULL),
./modules/ssl/ssl_scache_dbm.c:chown(apr_pstrcat(p,
mc->szSessionCacheDataFile, ".pag", NULL),
>
> This raised another bug in the next line. We assumed because we
> default to SYSV mutexes we should do that magic. I believe this is
> wrong, and we should be looking for that sort of lock explicitly.
>
+1. Note that we only call it if APR_USE_SYSVSEM_SERIALIZE is defined,
but the code itself is a noop unless APR_HAS_SYSVSEM_SERIALIZE is defined
(defined means 1). Good catch.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: Apache 2.0.45 -alpha tarball candidates for testing
William A. Rowe, Jr. wrote: The release tarball (and win32 .zip file) are now available for testing from; http://httpd.apache.org/dev/dist/ Note that child error functions other than in mod_cgid *are* horked due to log files being closed, but playing with mod_ext_filter and mod_cgi I don't see anything catastrophic, and I don't see a regression from the previous release. The attempt to write to the log file gets EBADF in the newly-created-but-doomed child process, and life goes on. As for the child error function support for failure to start piped loggers, that path is extremely hard to hit with the default code because the extra possible checking for errors is enabled (apr_procattr_error_check_set()). After commenting out the calls to apr_procattr_error_check_set() in log.c, I don't see any regression. uninteresting details of playing with piped loggers: I. httpd 2.0.45-alpha, no apr_procattr_error_check_set, prefork: A. bad piped access log: log message to stderr regarding the problem [error] (2)No such file or directory: exec of '/usr/bin/doesnotexist' failed log message to error log stating the problem regular attempts to restart it (that logic was broken in previous releases) it looks like there is always a zombie process, but it is a different zombie since there is some lag between a failed attempt to exec the piped log and when the MPM wakes up to reap status httpd is operational B. bad piped error log: log message to stderr regarding the problem httpd is operational II. httpd 2.0.44, unpatched, prefork: bad piped access log: no message to stderr httpd is operational bad piped error log: no message to stderr httpd is operational
Re: [PATCH] don't try to clean up listening sockets twice priorto exec
William A. Rowe, Jr. wrote: ++1 - makes perfect sense. One more oddball observation. Why repeatedly invoke the cleanups? We need only a few handles in cgid, it seems that setting those few handles aside and invoking cleanup_for_exec ourselves before we enter the server loop in the fork()ed cgid worker would speed things up quite considerably, over running cleanups hundreds of times. yeah, definitely some cleanup is needed as soon as cgid gets initialized; I can't even explain the stuff that cgid has open on one of my boxes I'm not sure how cgid is going to have the info to cleanup the unnecessary stuff or kill cleanups on the necessary stuff prior to invoking cleanup-for-exec, but I guess that is a minor detail.
Re: Apache 2.0.45 -alpha tarball candidates for testing
--On Monday, March 31, 2003 1:56 AM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: Please test this 2.0.45-alpha candidate for general release within the next 24 hours. Once the dev@ list receives enough positive feedback, we will release the files to general availability, moving them to their Builds, passes httpd-test (modulo my recent commit to httpd-test), and serves pages on Solaris 9 (with .44 modules). +1. -- justin
Re: cvs commit: httpd-2.0/build/rpm httpd.init httpd.logrotatehttpd.spec.in
--On Monday, March 31, 2003 10:09 AM +0200 Graham Leggett <[EMAIL PROTECTED]>
wrote:
The following code will pull the version number out of ap_release.h:
cat include/ap_release.h | grep "define AP_SERVER_MAJORVERSION" | cut -d' '
-f3 | tr -d '\"'
Is it portable?
FWIW, I'd use:
grep "^#define AP_SERVER_MAJORVERSION" include/ap_release.h | cut -d' ' -f3 |
tr -d '\"'
POSIX grep has limited regexp capabilities. The ^ is one of the supported
features, so that should be safe.
However, note that Greg used sed in APR's build/get-version.sh (which prints
out the version number for APR - similar task to what you need). So, you may
be able to do it like this:
major_sed="/#define.*$3_MAJOR_VERSION/s/^.*\([0-9][0-9]*\).*$/\1/p"
minor_sed="/#define.*$3_MINOR_VERSION/s/^.*\([0-9][0-9]*\).*$/\1/p"
patch_sed="/#define.*$3_PATCH_VERSION/s/^.*\([0-9][0-9]*\).*$/\1/p"
major="`sed -n $major_sed $2`"
minor="`sed -n $minor_sed $2`"
patch="`sed -n $patch_sed $2`"
echo ${major}.${minor}.${patch}
From a quick glance, the only thing you'd need to do is replace
MAJOR_VERSION's with MAJORVERSION's and invoke with:
./get-version.sh all include/ap_release.h AP_SERVER
That should work. You should also be able to tweak the script to respond to
an mmn request 'get-version.sh mmn include/ap_release.h AP_SERVER' or
something like that that spits out the current MMN. -- justin
Re: cvs commit: httpd-2.0/build/rpm httpd.init httpd.logrotate httpd.spec.in
Justin Erenkrantz wrote: Keep in mind that RPM isn't necessarily RedHat specific. Other platforms have RPMs available - IBM uses it for AIX, I think. Ok. The release manager elf changes it on bumping. -- justin The following code will pull the version number out of ap_release.h: cat include/ap_release.h | grep "define AP_SERVER_MAJORVERSION" | cut -d' ' -f3 | tr -d '\"' Is it portable? Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Apache 2.0.45 -alpha tarball candidates for testing
The release tarball (and win32 .zip file) are now available for testing from; http://httpd.apache.org/dev/dist/ Please test this 2.0.45-alpha candidate for general release within the next 24 hours. Once the dev@ list receives enough positive feedback, we will release the files to general availability, moving them to their usual locations. This code has been in place for several days on the primary www.apache.org server, but we need a variety of platforms and different configurations to have complete confidence in the release. Thank you in advance for participating in the testing, and thanks to both Brian Pane and Justin Erenkrantz who helped roll these out. Bill
