[STATUS] (flood) Wed Aug 14 23:46:10 EDT 2002
flood STATUS: -*-text-*- Last modified at [$Date: 2002/08/01 22:28:51 $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * DNS lookup failures in any urllist cause segfault. Justin says: Wow. Why? Aaron says: Is this still happening? It's been awhile. * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * It would be nice if a url in a urllist could handle basic authentication. * More analysis and graphing scripts are needed * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is
Current CVS on Win32
cache_cache.c C:\home\httpd-2.0\modules\experimental\cache_cache.c(58) : warning C4047: 'funct ion' : Anzahl der Dereferenzierungen bei 'long (__cdecl *)(void *)' und 'long (_ _cdecl ** )(void *)' unterschiedlich C:\home\httpd-2.0\modules\experimental\cache_cache.c(58) : warning C4024: 'cache _pq_init' : Unterschiedliche Typen fuer formalen und uebergebenen Parameter 2 C:\home\httpd-2.0\modules\experimental\cache_cache.c(87) : error C2064: Ausdruck ergibt keine Funktion C:\home\httpd-2.0\modules\experimental\cache_cache.c(89) : error C2064: Ausdruck ergibt keine Funktion C:\home\httpd-2.0\modules\experimental\cache_cache.c(98) : error C2064: Ausdruck ergibt keine Funktion C:\home\httpd-2.0\modules\experimental\cache_cache.c(104) : error C2064: Ausdruc k ergibt keine Funktion -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re[2]: perchild on FreeBSD 5?
Hi Ben Laurie, you wrote. BL Gabriel Ambuehl wrote: Am I correct assuming that when they are mutex'ed that there will be one instance of XX_lib PER perchild process, right? So eventually, each domain will be able to serve one request at a time? BL Surely not. It just means only one thread will be in the library at a time. I'm not really that experienced with regards to threading on Unix (once got burnt quite badly and burnt kids fear fire...) but if there is only one thread at a time allowed to be in the library there can only be one PHP request served (I might should have noted that I was referring to PHP requests) at a time by that process, no? Regards, Gabriel
Re[2]: perchild on FreeBSD 5?
Hi Rasmus Lerdorf, you wrote. time spent in mutex-protected code is 99% of the total request processing time, then the server will scale poorly. The key success factor is to not use libraries that require locking for lengthy operations. RL If, for example, we have to mutex an entire database library and every So it is expected to break up, for example, PHP in libraries that do support threading explicitely and such that don't or aren't known to do it instead of having a mutex around all of PHP? I'm aware of the fact that request for static content will still get served and that's very nice since many sites consist of few dynamic pages and loads of images ;-) so in the end, the scalability might not suffer too much in our case as we only host low traffic sites on shared servers anyway and on the dedicated ones, prefork has proven to offer quite acceptable performance. In view of this It's impossible to tell which libs are thread safe wouldn't it perhaps make sense to have a perchild version that uses processed instead of threads? I sure know that this would result in a insane amount of sleeping processes in a massive Virtualhosting setup but in my tests a very low end 500Mhz FreeBSD 4.6 box with 256MB RAM had no problem whatsoever with 2000 sleeping Apache processes belonging to 250 DISTINCT instances of 1.3.26, all based upon different config files and running on different ports . Swap wasn't used and in idle state, the 2000 processes consumed less than 1.5% CPU... Regards, Gabriel
Re: Current CVS on Win32
On Thu, 15 Aug 2002, Sebastian Bergmann wrote: cache_cache.c C:\home\httpd-2.0\modules\experimental\cache_cache.c(58) : warning C4047: 'funct ion' : Anzahl der Dereferenzierungen bei 'long (__cdecl *)(void *)' und 'long (_ _cdecl ** )(void *)' unterschiedlich Oh bother. :-/ I'll fix that up ASAP. --Cliff
Re: Re[2]: perchild on FreeBSD 5?
In view of this It's impossible to tell which libs are thread safe wouldn't it perhaps make sense to have a perchild version that uses processed instead of threads? I sure know that this would result in a insane amount of sleeping processes in a massive Virtualhosting setup but in my tests a very low end 500Mhz FreeBSD 4.6 box with 256MB RAM had no problem whatsoever with 2000 sleeping Apache processes belonging to 250 DISTINCT instances of 1.3.26, all based upon different config files and running on different ports . Swap wasn't used and in idle state, the 2000 processes consumed less than 1.5% CPU... While it is technicalloy possible to create a preforking server that operates like perchild, it isn't a simple thing to do. I would even go so far as to say that it isn't something you really want. If you want that behavior, the best solution is to just run multiple Apache servers. I looked at every MPM before creating perchild, and the only one that made a lot of sense for perchild was a static number of processes with a dynamic number of threads per process. If you have a dynamic number of processes, then the parent process must always determine how many child processes with each uid/gid exist currently. If you are going to do that, you are better off to just run two or three instances of prefork with an IP alias. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: perchild on FreeBSD 5?
Gabriel Ambuehl wrote: Hi Rasmus Lerdorf, you wrote. time spent in mutex-protected code is 99% of the total request processing time, then the server will scale poorly. The key success factor is to not use libraries that require locking for lengthy operations. RL If, for example, we have to mutex an entire database library and every So it is expected to break up, for example, PHP in libraries that do support threading explicitely and such that don't or aren't known to do it instead of having a mutex around all of PHP? No, not at all. The library partitioning is irrelevant: it's functions, not libraries, that have to be wrapped in mutexes if they're not thread-safe. Brian
Thread-unsafe libraries in httpd-2.0
[ Moving to dev@httpd where this belongs ] On Thu, Aug 15, 2002 at 07:10:02AM -0700, Rasmus Lerdorf wrote: Correct. From the feedback I am getting, users do not adequately understand the implications of choosing a threaded MPM. We need to do a better job educating them to the fact that we simple cannot guarantee which libraries are threadsafe and which are not. Precisely which libraries are the core of httpd-2.0 using in a thread-unsafe manner? At least in the core distribution, we should have knowledge of which libraries are thread-unsafe and prevent this. To my knowledge, I haven't seen a single problem related to this. If you have actual cases where httpd-2.0 is doing something unsafe, please let us know! I think perhaps your concern is simply to PHP which may bring in thread-unsafe libraries not httpd-2.0. -- justin
Re: Thread-unsafe libraries in httpd-2.0
On Thu, 15 Aug 2002, Justin Erenkrantz wrote: [ Moving to dev@httpd where this belongs ] On Thu, Aug 15, 2002 at 07:10:02AM -0700, Rasmus Lerdorf wrote: Correct. From the feedback I am getting, users do not adequately understand the implications of choosing a threaded MPM. We need to do a better job educating them to the fact that we simple cannot guarantee which libraries are threadsafe and which are not. Precisely which libraries are the core of httpd-2.0 using in a thread-unsafe manner? At least in the core distribution, we should have knowledge of which libraries are thread-unsafe and prevent this. To my knowledge, I haven't seen a single problem related to this. If you have actual cases where httpd-2.0 is doing something unsafe, please let us know! I think perhaps your concern is simply to PHP which may bring in thread-unsafe libraries not httpd-2.0. -- justin As I have stated a dozen times now. Yes, I am talking about PHP and any other add-on module people may use. I think the attitude of most people here sucks. Apache doesn't have a problem, why should we do anything? The reality is that a big chunk of our Apache community uses Apache to serve up complex dynamic content using PHP, mod_perl, other 3rd-party modules and homegrown modules as well. PHP and mod_perl alone are on well over 50% of all Apache servers. People don't look to Apache for simply serving up static content. A lot of sites replaced Apache long ago with thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. -Rasmus
Re: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 09:40:06AM -0700, Rasmus Lerdorf wrote: thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. Making broad statements that will confuse our users like threaded MPMs may not be suitable for serving up dynamic content is a ridiculously overbroad and inaccurate statement. A better statement may be: Some PHP or Perl modules may not interact well with a threaded MPM in httpd-2.0. Caution is urged when using a threaded MPM. To me, that totally belongs in the PHP or Perl documentation. That is a limitation of PHP and mod_perl not of httpd-2.0. That statement doesn't hold for a mod_jk2 (or whatever the latest httpd-2.0 Tomcat module is). It totally depends on how the 3rd party module is architected not on the architecture of the web server itself. -- justin
Re: Thread-unsafe libraries in httpd-2.0
EXACTLY. Thanks, Justin. We are not trying to shirk our responsibilities or be lazy about this. But you can't say my module is so popular that you must account for problems that I introduce into your environment. I'm fine with adding something to our document that says something along the lines of, if you choose a threaded MPM such as FOO, BAR, or BAZ, then you need to ensure that the third-party modules you choose to use with the web server are thread-safe. Please contact your third-party modules' vendors for more information on their thread-safety. -g On Thu, Aug 15, 2002 at 10:09:27AM -0700, Justin Erenkrantz wrote: On Thu, Aug 15, 2002 at 09:40:06AM -0700, Rasmus Lerdorf wrote: thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. Making broad statements that will confuse our users like threaded MPMs may not be suitable for serving up dynamic content is a ridiculously overbroad and inaccurate statement. A better statement may be: Some PHP or Perl modules may not interact well with a threaded MPM in httpd-2.0. Caution is urged when using a threaded MPM. To me, that totally belongs in the PHP or Perl documentation. That is a limitation of PHP and mod_perl not of httpd-2.0. That statement doesn't hold for a mod_jk2 (or whatever the latest httpd-2.0 Tomcat module is). It totally depends on how the 3rd party module is architected not on the architecture of the web server itself. -- justin -- Greg Stein, http://www.lyra.org/
Re: Thread-unsafe libraries in httpd-2.0
That's just crap. I can say the same thing. PHP is threadsafe, it's not my responsibility that libxyz is not. Any Apache 2.0 module running under a threaded mpm linked against libxyz that contains non-threadsafe code is going to have exactly the same problem unless the module sticks in mutexes. Right now in the PHP world we simply tell people that they should not upgrade to Apache 2.0. If everyone ends up doing that, then I am sorry to say, but Apache 2.0 is dead and the current Netcraft statement is going to be a recurring thing. As a platform there are some cool possibilities with Apache 2.0 and I'd like to see it do well, but as a module author, being told to piss off and deal with the problem myself is not any way to encourage 3rd-party module support for Apache 2.0. In the end the users out there don't really give a crap about which web server they use. They just want something that works. Apache was always the web server that just worked. I strongly feel it is our job to help make sure that Apache remain the web server that just works. Like it or not, but the web server is the foundation for all the projects under the ASF umbrella and if we fuck up Apache, every sub-project will be hurt in the process. -Rasmus On Thu, 15 Aug 2002, Greg Stein wrote: EXACTLY. Thanks, Justin. We are not trying to shirk our responsibilities or be lazy about this. But you can't say my module is so popular that you must account for problems that I introduce into your environment. I'm fine with adding something to our document that says something along the lines of, if you choose a threaded MPM such as FOO, BAR, or BAZ, then you need to ensure that the third-party modules you choose to use with the web server are thread-safe. Please contact your third-party modules' vendors for more information on their thread-safety. -g On Thu, Aug 15, 2002 at 10:09:27AM -0700, Justin Erenkrantz wrote: On Thu, Aug 15, 2002 at 09:40:06AM -0700, Rasmus Lerdorf wrote: thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. Making broad statements that will confuse our users like threaded MPMs may not be suitable for serving up dynamic content is a ridiculously overbroad and inaccurate statement. A better statement may be: Some PHP or Perl modules may not interact well with a threaded MPM in httpd-2.0. Caution is urged when using a threaded MPM. To me, that totally belongs in the PHP or Perl documentation. That is a limitation of PHP and mod_perl not of httpd-2.0. That statement doesn't hold for a mod_jk2 (or whatever the latest httpd-2.0 Tomcat module is). It totally depends on how the 3rd party module is architected not on the architecture of the web server itself. -- justin -- Greg Stein, http://www.lyra.org/
Re: Thread-unsafe libraries in httpd-2.0
Rasmus Lerdorf wrote: That's just crap. I can say the same thing. PHP is threadsafe, it's not my responsibility that libxyz is not. Any Apache 2.0 module running under a threaded mpm linked against libxyz that contains non-threadsafe code is going to have exactly the same problem unless the module sticks in mutexes. how are we .. the apache group know what libraries you link to ? the only thing I can suggest technically is that we add a field in the module definition which says if the module is thread_safe. it would be up to the module developer to determine this, either based on the libraries he has linked in, or what color the trees are. if the module developer isn't certain about the thread safety of linked libraries he should set it to off. php could be really smart about this, and do this for it's own extensions.. and use the result of querying it's own extension for their thread safety. as the php extension developers certify their extensions php will be either thread safe or not. we as the apache group could then query the module when we load it (like we do to the magic number) and refuse to load a non-thread safe module into a threaded mpm. does this sound ok to you? snip
Re: Thread-unsafe libraries in httpd-2.0
That's not a bad idea, methinks. It would at least give us a reliable way to print an error message letting the user know why module foo can't be loaded: please try prefork if you need to use this module. Better than weird errors later in runtime. But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do the same. -wsv On Thursday, August 15, 2002, at 01:43 PM, Ian Holsman wrote: the only thing I can suggest technically is that we add a field in the module definition which says if the module is thread_safe.
Re: [PATCH] Added IfModule wrappers to httpd-std.conf.in (fwd)
OK, so do people really hate the IfModule wrappers? Because I wanna commit it. Votes? We have +1 from Fred, Ian and a 0 of some flavor from Joshua. -wsv
Re: Thread-unsafe libraries in httpd-2.0
But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do the same. This is how I understood Ian's suggestion. That PHP asks its extensions whether they're thread-safe or not. And PHP itself tells Apache whether it - as a whole, i.e. including its extensions - is thread safe. j. -- A conference is a gathering of important people who singly can do nothing, but together can decide that nothing can be done. -- Fred Allen - http://jgcl.at/ko/ - new photos from summer camp 2002 in Moosen/Tirol
Re: [PATCH] Added IfModule wrappers to httpd-std.conf.in (fwd)
On Thu, 15 Aug 2002, Wilfredo Sanchez wrote: We have +1 from Fred, Ian and a 0 of some flavor from Joshua. -0 Hesitant but I won't stand in the way.
Re: Thread-unsafe libraries in httpd-2.0
Wilfredo Sanchez wrote: That's not a bad idea, methinks. It would at least give us a reliable way to print an error message letting the user know why module foo can't be loaded: please try prefork if you need to use this module. Better than weird errors later in runtime. But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do the same. exactly. php would ask it's extensions that are loaded/built in if they are threadsafe, and if any weren't then it would respond no until php has this functionality it could just return a blanket no this would work as long as php doesn't dynamically load extensions at request time. if it does then it could refuse to load a non-threaded dynamic extension into a already running threaded php. -wsv On Thursday, August 15, 2002, at 01:43 PM, Ian Holsman wrote: the only thing I can suggest technically is that we add a field in the module definition which says if the module is thread_safe.
Re: [PATCH] Added IfModule wrappers to httpd-std.conf.in (fwd)
On Thu, Aug 15, 2002 at 01:53:58PM -0400, Cliff Woolley wrote: On Thu, 15 Aug 2002, Wilfredo Sanchez wrote: We have +1 from Fred, Ian and a 0 of some flavor from Joshua. -0 Hesitant but I won't stand in the way. Same here, -0. -aaron
Re: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 07:57:02PM +0200, johannes m. richter wrote:
But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do
the same.
This is how I understood Ian's suggestion. That PHP asks its extensions
whether they're thread-safe or not. And PHP itself tells Apache whether it
- as a whole, i.e. including its extensions - is thread safe.
FWIW, this infrastructure is already present within httpd-2.0.
ap_mpm_query(AP_MPMQ_IS_THREADED, *foo);
if (foo != AP_MPMQ_NOT_SUPPORTED) {
...we have threads...
}
HTH. -- justin
Re: Thread-unsafe libraries in httpd-2.0
Justin Erenkrantz wrote:
On Thu, Aug 15, 2002 at 07:57:02PM +0200, johannes m. richter wrote:
But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do
the same.
This is how I understood Ian's suggestion. That PHP asks its extensions
whether they're thread-safe or not. And PHP itself tells Apache whether it
- as a whole, i.e. including its extensions - is thread safe.
FWIW, this infrastructure is already present within httpd-2.0.
ap_mpm_query(AP_MPMQ_IS_THREADED, *foo);
if (foo != AP_MPMQ_NOT_SUPPORTED) {
...we have threads...
}
it's not as obvious, the proposal above forces the developer to say
i verify my module will work with threaded
HTH. -- justin
proxy cgi no longer streamed, C-L filter buffers
With 2.0.40 content coming from mod_proxy and mod_cgi is no longer streamed to the client but sent in one big chunk. It appears that the C-L filter now buffers the data in every case. For certain applications this is a very undesirable feature, and it would be very helpful if the C-L filter could be bypassed (and simply not send back a C-L header). In 2.0.32 streaming behaved beautifully. Then in 2.0.36 and 2.0.39 the C-L filter started buffering large chunks. Now in 2.0.40 everything is buffered and a C-L header is always inserted. Could the 2.0.32 streaming/C-L behavior be brought back, perhaps enabled by a config option? Blaise
Re: Thread-unsafe libraries in httpd-2.0
FWIW, I'm +1 on what Rasmus says - at least for widely used libraries. Obviously anything internal to PHP is PHP's problem. But anything everyone uses is our problem. However, I would advocate fixing the libraries rather than wrapping them where possible. Yup, definitely. They aren't always open source or sometimes they are just architecturally not fixabled. Step 1 is to gather information. I have committed an initial short list to httpd-2.0/docs/manual/developer/thread_safety.html where I plan on keeping track of stuff as the PHP bug reports flow in or I dive into each library to check out the code. -Rasmus
Re: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 11:51:52AM -0700, Ian Holsman wrote: it's not as obvious, the proposal above forces the developer to say i verify my module will work with threaded No, I'd much prefer that modules code their own checks for it. A simple check in the pre_config hook phase should be sufficient. The PHP case would have to be done dynamically - it can't be done at compile-time, so a flag in the module structure at compile-time would not work. It would almost have to do something like I outlined before with a revamp of its extensions framework to indicate if a PHP extension is known-to-be thread-safe. -- justin
[Patch] Move configure argument parsing into apr
This is the twin of the commit I just did on APR, just to minimise duplication. Cheers, -Thom -- Thom May - [EMAIL PROTECTED] Knghtbrd- for the record: Knghtbrd- AGH! * Knghtbrd- gets back to abusing gdm Index: acinclude.m4 === RCS file: /home/cvspublic/httpd-2.0/acinclude.m4,v retrieving revision 1.126 diff -u -r1.126 acinclude.m4 --- acinclude.m416 Jul 2002 18:33:05 - 1.126 +++ acinclude.m415 Aug 2002 17:32:53 - @@ -501,127 +501,6 @@ fi ]) -dnl -dnl APACHE_PARSE_ARGUMENTS -dnl a reimplementation of autoconf's argument parser, -dnl used here to allow us to co-exist layouts and argument based -dnl set ups. -AC_DEFUN(APACHE_PARSE_ARGUMENTS,[ -ac_prev= -for ac_option -do - # If the previous option needs an argument, assign it. - if test -n $ac_prev; then -eval $ac_prev=\$ac_option -ac_prev= -continue - fi - - ac_optarg=`expr x$ac_option : 'x[[^=]]*=\(.*\)'` - - case $ac_option in - - -bindir | --bindir | --bindi | --bind | --bin | --bi) -ac_prev=bindir ;; - -bindir=* | --bindir=* | --bindi=* | --bind=* | --bin=* | --bi=*) -bindir=$ac_optarg ;; - - -datadir | --datadir | --datadi | --datad | --data | --dat | --da) -ac_prev=datadir ;; - -datadir=* | --datadir=* | --datadi=* | --datad=* | --data=* | --dat=* \ - | --da=*) -datadir=$ac_optarg ;; - - -exec-prefix | --exec_prefix | --exec-prefix | --exec-prefi \ - | --exec-pref | --exec-pre | --exec-pr | --exec-p | --exec- \ - | --exec | --exe | --ex) -ac_prev=exec_prefix ;; - -exec-prefix=* | --exec_prefix=* | --exec-prefix=* | --exec-prefi=* \ - | --exec-pref=* | --exec-pre=* | --exec-pr=* | --exec-p=* | --exec-=* \ - | --exec=* | --exe=* | --ex=*) -exec_prefix=$ac_optarg ;; - - -includedir | --includedir | --includedi | --included | --include \ - | --includ | --inclu | --incl | --inc) -ac_prev=includedir ;; - -includedir=* | --includedir=* | --includedi=* | --included=* | --include=* \ - | --includ=* | --inclu=* | --incl=* | --inc=*) -includedir=$ac_optarg ;; - - -infodir | --infodir | --infodi | --infod | --info | --inf) -ac_prev=infodir ;; - -infodir=* | --infodir=* | --infodi=* | --infod=* | --info=* | --inf=*) -infodir=$ac_optarg ;; - - -libdir | --libdir | --libdi | --libd) -ac_prev=libdir ;; - -libdir=* | --libdir=* | --libdi=* | --libd=*) -libdir=$ac_optarg ;; - - -libexecdir | --libexecdir | --libexecdi | --libexecd | --libexec \ - | --libexe | --libex | --libe) -ac_prev=libexecdir ;; - -libexecdir=* | --libexecdir=* | --libexecdi=* | --libexecd=* | --libexec=* \ - | --libexe=* | --libex=* | --libe=*) -libexecdir=$ac_optarg ;; - - -localstatedir | --localstatedir | --localstatedi | --localstated \ - | --localstate | --localstat | --localsta | --localst \ - | --locals | --local | --loca | --loc | --lo) -ac_prev=localstatedir ;; - -localstatedir=* | --localstatedir=* | --localstatedi=* | --localstated=* \ - | --localstate=* | --localstat=* | --localsta=* | --localst=* \ - | --locals=* | --local=* | --loca=* | --loc=* | --lo=*) -localstatedir=$ac_optarg ;; - - -mandir | --mandir | --mandi | --mand | --man | --ma | --m) -ac_prev=mandir ;; - -mandir=* | --mandir=* | --mandi=* | --mand=* | --man=* | --ma=* | --m=*) -mandir=$ac_optarg ;; - - -prefix | --prefix | --prefi | --pref | --pre | --pr | --p) -ac_prev=prefix ;; - -prefix=* | --prefix=* | --prefi=* | --pref=* | --pre=* | --pr=* | --p=*) -prefix=$ac_optarg ;; - - -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) -ac_prev=sbindir ;; - -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ - | --sbi=* | --sb=*) -sbindir=$ac_optarg ;; - - -sharedstatedir | --sharedstatedir | --sharedstatedi \ - | --sharedstated | --sharedstate | --sharedstat | --sharedsta \ - | --sharedst | --shareds | --shared | --share | --shar \ - | --sha | --sh) -ac_prev=sharedstatedir ;; - -sharedstatedir=* | --sharedstatedir=* | --sharedstatedi=* \ - | --sharedstated=* | --sharedstate=* | --sharedstat=* | --sharedsta=* \ - | --sharedst=* | --shareds=* | --shared=* | --share=* | --shar=* \ - | --sha=* | --sh=*) -sharedstatedir=$ac_optarg ;; - - -sysconfdir | --sysconfdir | --sysconfdi | --sysconfd | --sysconf \ - | --syscon | --sysco | --sysc | --sys | --sy) -ac_prev=sysconfdir ;; - -sysconfdir=* | --sysconfdir=* | --sysconfdi=* | --sysconfd=* | --sysconf=* \ - | --syscon=* | --sysco=* | --sysc=* | --sys=* | --sy=*) -sysconfdir=$ac_optarg ;; - - esac -done - -# Be sure to have absolute paths. -for ac_var in exec_prefix prefix -do - eval ac_val=$`echo $ac_var` - case $ac_val in -[[\\/$]]* | ?:[[\\/]]* | NONE | '' ) ;; -*) AC_MSG_ERROR([expected an absolute path for --$ac_var: $ac_val]);; - esac -done - -])dnl dnl dnl APACHE_EXPORT_ARGUMENTS Index: configure.in ===
resolving SSL with mod_ssl.so
Hi, Building 2.0.40 on Tru64 I am seeing issues with building a resolved mod_ssl.so. I am using OpenSSL with the SSL libs built static. I get messages about unresolved symbols when loading mod_ssl. I chased it down but need some advice on a real resolution. As you all know, mod_ssl needs to resolve against -lss -lcrypto. What I am seeing is that: Configure: * correctly detects that SSL is desired, * finds the libs in the right place (I specify the location), * knows that additional libraries, -lssl and -lcrypto are needed. * adds -lssl and -lcrypto to EXTRA_LIBS We are golden so far ... if we are building a static httpd, but I want to build apache DSO. When linking http, I do see the EXTRA_LIBS on the link line... But... I am building mod_ssl.so, so there are no SSL calls in httpd to resolve against, so in effect, the EXTRA_LIBS are ignored when linking httpd. If my SSL libraries were built shared, then the linker would put a runtime requirement into the httpd image that would load the SSL libs, but my SSL libs are static. So, normally I would expect that the link command creating mod_ssl.so would include the needed EXTRA_LIBS, but I don't see any provision for this. Hacking modules/ssl/modules.mk and adding -lssl -lcrypto, and makeing mod_ssl.la I do end up with a fully resolved mod_ssl.so Am I missing something dreadfully obvious here ? It would seem to me that other than the static httpd case, resolving all DSO against -lssl -lcrypto is not the right thing to do. If my SSL libs were shared, then each of the DSO modules would load the SSL libs regardless if they were needed or not. Given the size of the SSL libs that is a pain. The right answer (?) would seem to be configure setting SSL_LIBS, and somehow inserting them into the proper place depending on where they are needed (httpd link or the mod_ssl.so link). So any words of wisdom or thoughts from you build gurus out there ? thanks, Dave Hill
Re: 2.0.40 Win32 binary packages borked
At 11:14 AM 8/12/2002, Cliff Woolley wrote: The .msi and .exe installers for 2.0.40 are borked... lots of default stuff (license, etc), and the registry keys created are apparently for 2.0.39 instead of 2.0.40 (or so says one of the several PR's on the matter). This was my fault, entirely, so I'm starting with my apologies for leaping without looking. I'd upgraded my machine to InstallShield Developer (7.0.4) while the earlier packages were all built with InstallShield for Windows Installer (1.5.3). Apparently it's converters were not sufficiently complete. How soon can these be rebuilt? Should I pull the broken installers in the meanwhile? The new binaries are checked into the usual location. I checked the install against an nmake -f makefile.win INSTDIR=... style install, and nothing seems to be missing. Again, my apologies, and I'll take some time to figure out why the ISDE flavor isn't correct. Since we can no longer obtain ISWI, these need to be migrated anyways. And finally, I'll go back to my ancient project of building the perl classes required to access the .msi and .cab (diamond) interfaces for building these .msi files programmatically, so we don't run into these problems again. Really, ISDE (ISWI) were only needed to create the original dialogs and other packaging. Now that we have a complete package, it 'should' be pretty trivial to rebuild the .cab file on the fly, and that would only require perl and the SDK for someone else to churn out binaries. Investigating. Bill
Re: cvs commit: httpd-2.0/docs/manual/developer thread_safety.html
[EMAIL PROTECTED] wrote: rasmus 2002/08/15 12:14:47 Added: docs/manual/developer thread_safety.html Log: Many more to come - just committing to get the framework in there so people can start adding to it. VERY cool! -- === 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: cvs commit: httpd-dist/binaries/win32 README.html
On 15 Aug 2002 [EMAIL PROTECTED] wrote: wrowe 2002/08/15 11:46:46 Modified:binaries/win32 README.html Log: Thanks to whomever simply commented this out... makes it simple to recover it :-) You're welcome. Thanks for doing the rebuild! --Cliff
Re: daedalus is running 2.0.40 live
On Fri, 9 Aug 2002, Greg Ames wrote: portable way to do this. Maybe I should just hack apbounce to look for a listener on port 80 once a second or something. I usually make my restart the httpd script look for the pid, run apachectl stop and then wait until you can't kill(pid, 0) anymore before proceeding. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
httpd-dist directory descriptions
The .htaccess file isn't setup correctly to display the descriptions of the directories. Shane Index: .htaccess === RCS file: /home/cvspublic/httpd-dist/.htaccess,v retrieving revision 1.78 diff -u -r1.78 .htaccess --- .htaccess 9 Aug 2002 19:31:06 - 1.78 +++ .htaccess 16 Aug 2002 03:02:13 - -33,7 +33,7 AddDescription List of changes in 1.3 CHANGES_1.3 AddDescription List of changes in 2.0 CHANGES_2.0 AddDescription Developer PGP/GPG keys KEYS -AddDescription Binary distributions binaries -AddDescription Contributed software contrib -AddDescription Old source amp; binaries old -AddDescription Official patches patches +AddDescription Binary distributions binaries/ +AddDescription Contributed software contrib/ +AddDescription Old source amp; binaries old/ +AddDescription Official patches patches/
Re[2]: Why can't ap_send_error_response() count on charset?
Hello! Well, it's maybe not so close to the subject... But... I'm faced up with some problem with the type-map files (yes, for example, with default error pages in Apache distribution). Who can tell me, what is the next line (that can be inserted in type-map files) exactly means: Content-type: text/html;charset=WINDOWS-1251 This is from index.html.var (htdocs dir). Ok, this is my problem: i just translated all error pages into my own language (Russian), for example, next lines from HTTP_NOT_FOUND.html.var: [... previous languages ...] Content-language: ru Content-type: text/html;charset=WINDOWS-1251 Body:--ru-- !--#set var=TITLE value=Object not found! -- !--#include virtual=include/top.html -- The requested URL was not found on this server. (Assume it's in Russian). Bla-bla-bla... !--#include virtual=include/bottom.html -- --ru-- Is it Ok ;)??? It is Ok! But when i try to see it ;), i've got a non readable page (page tagged in header such as it in AddDefaultCharset (ISO-8859-1) charset). It seems that Content-type: text/html;charset=WINDOWS-1251 means NOTHING (at last in terms of charset). It is simply not work (or maybe i simply don't understand meaning of this line ;)??? I can put all error text in the file and rewrite all Body section to URI: error.html but this will not change anything. I MUST add .ru.cp-2151 extension to this file so mod_mime can wake up... General question: Is it possible to define a charset in type-map files (for Body sections)??? Best regards, Denis.
Re: httpd-dist directory descriptions
On Thu, 15 Aug 2002, David Shane Holden wrote: The .htaccess file isn't setup correctly to display the descriptions of the directories. Committed, thanks. --Cliff
Re: Thread-unsafe libraries in httpd-2.0
At 03:04 PM 8/15/2002, Justin Erenkrantz wrote: On Thu, Aug 15, 2002 at 11:51:52AM -0700, Ian Holsman wrote: it's not as obvious, the proposal above forces the developer to say i verify my module will work with threaded No, I'd much prefer that modules code their own checks for it. A simple check in the pre_config hook phase should be sufficient. The answer i verify my module won't work threaded and emitting a warning [or outright error] should be more than sufficient. This allows PHP to collect the extensions it's loading and decide if thread safety is a hazard or those extensions are explicitly trusted for thread safety. I think it's bogus to state that Apache 2.0 is causing the pain. If you don't want to be loaded in a threaded server, say so in your preconfig. There's no reason to bloat all of Apache and it's well behaved modules with extra code, when only a handful of modules care to report that they can't be compiled for a threaded architecture. Justin is right on here. Bill
