Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_easy_reports.c flood_farm.c flood_net.c flood_net_ssl.c flood_report_relative_times.c
On Thu, Aug 23, 2001 at 10:35:50PM -0700, Justin Erenkrantz wrote: On Fri, Aug 24, 2001 at 04:26:39AM -, [EMAIL PROTECTED] wrote: jerenkrantz01/08/23 21:26:39 Modified:floodconfig.h.in configure.in flood.c flood_easy_reports.c flood_farm.c flood_net.c flood_net_ssl.c flood_report_relative_times.c Log: Per Sander, Linux 2.4 returns EAGAIN when we run out of ports. This was a royal screw-up on my part. I only meant to commit flood_net.c, but all of the fork stuff slipped in. It wasn't really ready for commit. But, uh, yeah, it's there now. =) I'll test it some more (it works) and then I'll commit lines to CHANGES with what I really changed on this commit. *sigh* -- justin After looking through the changes I'm not so sure this is what we want. I'd rather not treat threads and forked processes the same, since we may want to mix the two. The fork()ed scenario was what we originally defined as a collective, which is basicly a bunch of farms with each farm running in a single process. I'm worried that we're losing flexibility here, at least in terms of properly emulating some real-world clients (like a browser that truely uses threads). This may just be invalid paranoia on my part, but at this time I see no good reason to restrict ourselves. I like using conditional compilation for things like optimizing OpenSSL usage, but I don't like it for deciding what a farmer does. Anyway, I realize that this was a premature commit, but I thought I'd voice my objections anyway ;) BTW, I'm glad to see we're going to support fork()ing soon :) -aaron
Re: cvs commit: httpd-test/flood CHANGES flood_farm.c
On Fri, Aug 24, 2001 at 05:59:58AM -, [EMAIL PROTECTED] wrote: jerenkrantz01/08/23 22:59:58 Modified:floodCHANGES flood_farm.c Log: Okay, here's the real commit log for the fork()-based implementation of flood. - Remove FLOOD_USE_THREADS as we have no way of determining if we have threads other than APR. (We'd say that threads were always enabled.) I feel comfortable using APR's thread detection rather than mucking with parameters ourselves. - Add strtoq conversion for FreeBSD that #defines it to strtoll. This is a tad cheesy. Thoughts? I don't want to have #ifdef HAVE_STRTOLL and #ifdef HAVE_STRTOQ all over the place. Smells like an APR function. does linux have strtoll? IIRC, we're just reading it into an 'int' anyway, so why the long long? - Remove forking stuff in flood.c as it doesn't make sense to fork() here anyway as this is only bootstrap code. - Make reports output either the current thread id or the pid I assume this is only temporary until we have a better GUID? We really shouldn't be calling apr_os_thread_id() and then trying to print it as an int. How about just a counter for each new thread/process? - Don't do OpenSSL locking when we aren't threaded cool. - Not all OpenSSL versions (FreeBSD 4.2 has 0.9.5a) has AUTO_RETRY. So, only set that option if we have that symbol. So, we now support FreeBSD. Go forth. very cool. -aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
On Fri, Aug 17, 2001 at 09:30:24AM -0700, Justin Erenkrantz wrote: [ CCing [EMAIL PROTECTED] - this came about due to flood requiring a PRNG... ] On Fri, Aug 17, 2001 at 09:21:06AM -0700, Aaron Bannert wrote: Really this should be in APR, but I fear that PRNG is a touchy subject for portability. The problem is that when you're using a PRNG, you usually need to know the operating parameters of the PRNG, like what you ran in to: period, distribution, etc... If we put an abstraction into APR, we may end up with lowest-common-denominator-syndrome, where it becomes less than useful for cases that require specific amounts of entropy. What do you think? Knuth Vol. 2 or Numerical Recipies in C. =-) Both have fairly large and detailed sections on PRNGs. (I have both books.) I don't see a problem adding a PRNG into APR as long as we have a by default good one available with known characteristics. -- justin Um... APR *already* has random stuff in there. It can build against the truerand library, and it can use the /dev/random device. If we have a small hunk of PRNG code, that would be great. Unfortunately, though, it would be rather difficult to feed APR with a lot of entropic data. (i.e. where/how would it come from?) But just a good PRNG function would be handy, I'd think. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
I don't see a problem adding a PRNG into APR as long as we have a by default good one available with known characteristics. -- justin Um... APR *already* has random stuff in there. It can build against the truerand library, and it can use the /dev/random device. If we have a small hunk of PRNG code, that would be great. Unfortunately, though, it would be rather difficult to feed APR with a lot of entropic data. (i.e. where/how would it come from?) PRNG == pseudo-random number generator == repeatable so that simulations can be repeated for analysis I don't know if it would be useful in apr or not. Roy
Re: is apache building properly for anybody on Darwin?
# httpd - temporary wrapper script for .libs/httpd # Generated by ltmain.sh - GNU libtool 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) # # The httpd program cannot be directly executed until all the libtool # libraries that it depends on are installed. # Huh? Okay, I confess ignorance, but this looks like very bad news. Now we need libtool libraries to -run- Apache? If that is the case, then I feel a -1 (and that's a veto) coming on :-) Bill
Re: 2.0.24 ready for beta?
Greg Stein [EMAIL PROTECTED] writes: On Thu, Aug 23, 2001 at 02:53:03PM -0400, Greg Ames wrote: ... However, the bugs are getting more subtle and take longer to debug and fix. With our current process, a great deal of new code can be committed while the gnarly problem in last tarball is being debugged. Why would we think that the new code is any less likely to contain serious bugs than the previous set of changes? How do we get off this treadmill? We got off the treadmill by stopping this silly business of holding up tarballs. Snap a tarball. Give it a once over. Release it as an alpha. Bam. Done. Come back a week later and upgrade it to a beta. Not so hard. I don't think you can accurately equate the desire by some people to put together a tarball which they expect will be of beta quality with holding up tarballs. Anybody that wants an alpha is free to do so. As it stands, it seems that the only folks that are interested in a tarball only want it if they think it is beta quality. Somebody who isn't so picky is free to follow the process you outline above. As long as those who want a beta tarball are helping the code base I think they should be allowed to deviate from that process (e.g., re-tag files later when necessary fixes are applied, in effect maintaining a virtual tarball until it is ready). As I see it from the frontlines of debugging the current code, the test/debug cycle, and its overlap with lots of activity in HEAD, is what is delaying a beta tarball. I don't see how the process you outlined is going to change that, unless there are some different psychological motivations in play which will reduce the amount of activity in HEAD and/or apply additional effort to the test/debug cycle. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: is apache building properly for anybody on Darwin?
Bill Stoddard [EMAIL PROTECTED] writes: # httpd - temporary wrapper script for .libs/httpd # Generated by ltmain.sh - GNU libtool 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) # # The httpd program cannot be directly executed until all the libtool # libraries that it depends on are installed. # Huh? Okay, I confess ignorance, but this looks like very bad news. Now we need libtool libraries to -run- Apache? If that is the case, then I feel a -1 (and that's a veto) coming on :-) s/libtool libraries/libraries built by libtool, such as apr and apr-util/ Everything seems cool after an install*, and dsos haven't been proper until an install for a while anyway, so no big deal. Just be aware that if you don't run the installed version you're really running a shell script which in turn runs .libs/lt-httpd or .libs/lt-ab or whatever. *except on Darwin AFAIK; I'll assume somebody else has had a look-see on Solaris and I'll try to have a look-see on AIX today -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Win32 compile breakage...
Is awk installed? Somehow managed to get the wrong awk.exe wrapping the wrong gawk.exe. Try Windows Script Host ( WSH ), (always there, always ready), since Apache now fully supports Windows OS (and IE) tools! :) JLW
appending to the content brigade
I'm implementing a content filter which wraps the content in multipart
mime. I can generate a separator, my data, separator, original payload
and separator. The problem is that if I just concatonate the brigades,
I end up with an EOS before my final separator. This works (the final
bucket gets sent down the wire) but, if I understand the meaning of
EOS I won't get into heaven this way. I figured I could copy all but
the EOS from the original payload to the new brigade:
-APR_BRIGADE_CONCAT(bsend, bPayload);
+APR_BRIGADE_FOREACH(e, bPayload) {
+ if (!APR_BUCKET_IS_EOS(e))
+ APR_BRIGADE_INSERT_TAIL(bsend, e);
+}
#...
apr_brigade_destroy(bPayload);
e = apr_bucket_pool_create(boundary, boundryLength, r-pool);
APR_BRIGADE_INSERT_TAIL(bsend, e);
e = apr_bucket_eos_create();
APR_BRIGADE_INSERT_TAIL(bsend, e);
This corrupted bsend on the first insert. I hadn't even gotten as far
as destroying bPayload, which I expected to be a bad idea. The
byterange filter uses some function calls to copy pieces of the
brigade. Is this the sanctioned approach?
--
-eric
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
RE: cvs commit: httpd-2.0/modules/ssl mod_ssl.c ssl_engine_io.c
Hi,
Pl. see my comments below ..
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 24, 2001 11:07 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: httpd-2.0/modules/ssl mod_ssl.c ssl_engine_io.c
dougm 01/08/24 11:06:47
Modified:modules/ssl mod_ssl.c ssl_engine_io.c
Log:
enable i/o debugging
Revision ChangesPath
1.28 +1 -6 httpd-2.0/modules/ssl/mod_ssl.c
Index: mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- mod_ssl.c 2001/08/24 00:09:30 1.27
+++ mod_ssl.c 2001/08/24 18:06:47 1.28
@@ -285,12 +285,7 @@
*/
SSL_set_tmp_rsa_callback(ssl, ssl_callback_TmpRSA);
SSL_set_tmp_dh_callback(ssl, ssl_callback_TmpDH);
-#if 0 /* XXX */
-if (sc-nLogLevel = SSL_LOG_DEBUG) {
-BIO_set_callback(SSL_get_rbio(ssl), ssl_io_data_cb);
-BIO_set_callback_arg(SSL_get_rbio(ssl), ssl);
-}
-#endif
+
WHY ?.. We've got to enable DEBUG (if the user wants it).. I'd prefer to
have it..
Thanks
-Madhu
Re: Ryan's comments about split_and_pass_pretag_buckets.
The big problem, is that this shouldn't be a function, it should be a macro. Ryan On Friday 24 August 2001 18:59, William A. Rowe, Jr. wrote: - Original Message - From: Paul J. Reder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 24, 2001 6:02 PM Subject: Re: Ryan's comments about split_and_pass_pretag_buckets. Ryan, I am in the process of digging myself out of a weeks worth of lost mail, but I am working to address the issues with my commited patch to mod_cgi, mod_cgid, and mod_include. Unless you have another preference, I will be moving the code to a common location in util_filter.c. Huh? util_script exists soley to support the modules you just mentioned. Unless, as rbb points out, that the facilities will never be used outside of mod_include -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Fri, Aug 24, 2001 at 04:39:32PM -0400, Cliff Woolley wrote: ... It just occurred to me that by the time we arrive at this particular block, the byterange filter should have normalized all such buckets because it calls apr_brigade_length(), which reads in all buckets of indeterminate length. So this block is probably never reached, but it's worthwhile to have it right anyway. It should be right. It would be very easy for a bucket to be based on a pipe or a socket, thus being uncopyable, but it knows the length of data to be read from that pipe/socket. Imagine if you have a particular protocol running over some socket to a backend server. You know the next chunk of data is 1000 bytes. You insert your custom socket bucket, saying this socket, 1000 bytes. It can be read, but it can't be copied. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: 2.0.24 and ssl and perchild
On Sun, Aug 26, 2001 at 02:04:26AM +0200, Gomez Henri wrote: The problem I related previously appears only when using --with-mpm=perchild No problem with threaded or worker I'm not sure if anyone is maintaining perchild. -- justin
Re: recommanded configure for 2.0.24 ?
On Sun, Aug 26, 2001 at 02:06:53AM +0200, Gomez Henri wrote: May be the following is more recommanded ? ./configure \ --with-mpm=threaded \ --enable-so \ --enable-module=all \ --enable-mods-shared=all \ --enable-so \ --enable-ssl --with-ssl=/usr/include/ Yes, I'd recommend this one as it is much cleaner. =-) Maybe --enable-mods-shared=most as it will disable modules that aren't supported on your platform (all will stop if it finds a module that can't be built). I wouldn't specify the --with-mpm as this allows us to specify the MPM. Our default is prefork for a good reason. =-) -- justin Yes, on Linux prefork is selected by default. threaded seems to works fine, but perchild is no more useable since mod_ssl failed to build. Using prefork mode on Linux make Apache 2.0 equivalent to Apache 1.3 ? No more threads in that case ? I've got a question for you gurus, I'm working on mod_jk, tomcat connector, and I must make some task ONLY one time, regardless of MPM used (threading, forked, mixed). What strategy could I use ?
Re: .libs/httpd
On Friday 24 August 2001 14:40, Greg Stein wrote: On Fri, Aug 24, 2001 at 01:50:06PM -0700, Ryan Bloom wrote: On Friday 24 August 2001 13:51, Greg Stein wrote: On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote: ... Please don't do that. Passing --disable-shared is what caused the shared modules to stop working. Apache should be able to work as one big monolithic executable. Shared modules should still be able to work because Apache would still have DSO loading capabilities. But as I said, libtool sucks. Basically, libtool 1.4 has combined ltconfig and libtool into one executable. If you pass --disable-shared to the configure step, the libtool is built in such a way, that it can no longer create shared libraries. That has nothing to do with libtool. You configured the system to build things as static libraries. Why would you suddenly expected the *output* of that configuration to be able to build shared libs? Even so, an external module could be built as a shared lib, and loaded by that monolithic Apache. And hey... maybe somebody built a monolithic Apache *specifically* to disallow new modules. So I'm not sure why your undies are all in a bunch about libtool and the --disable-shared switch. Because it is absolutely bogus that I have to choose whether EVERYTHING in the build is static or dynamic. I should be able to configure APR to be built as a static lib, but still have shared modules. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
MM
Quick Question - Is MM support still available and if yes, how do I enable it (--enable-sms ?) Thanks -Madhu
Re: recommanded configure for 2.0.24 ?
On Sun, Aug 26, 2001 at 02:19:54AM +0200, Gomez Henri wrote: Yes, on Linux prefork is selected by default. threaded seems to works fine, but perchild is no more useable since mod_ssl failed to build. Yeah, but there are outstanding issues with threaded MPM that make me leery of recommending threaded for end-users until we resolve them. Threaded MPM works, but there are some issues that I don't think can be resolved in the current code. The long-term alternative is the worker MPM - Aaron just submitted (and rbb committed) a patch that should go a long way to get worker MPM up. I haven't had a chance to test it yet, but I will try to do so soon. If you want to try out threads, you may want to try the worker MPM. (God, these MPM names are wretched.) Using prefork mode on Linux make Apache 2.0 equivalent to Apache 1.3 ? No more threads in that case ? Yeah. On Linux, threads are equivalent to processes anyway, so it isn't a big deal. Solaris is a different story though. I've got a question for you gurus, I'm working on mod_jk, tomcat connector, and I must make some task ONLY one time, regardless of MPM used (threading, forked, mixed). The post_config hook is probably your best bet. -- justin
RE: [PATCH] fix session caching
Oops.. I forgot to put in the explaination itself :-).. From Geoff's mail ... snip ... So, the fix is to change mod_ssl to force OpenSSL to ignore process local-caching and to always get/set/delete sessions using mod_ssl's callbacks. The latest version of mod_ssl (2.8.4), at about line 604 of ssl_engine_init.c, is where the cache options are set for OpenSSL when caching isn't completely disabled. Ie. ..snip.. -Original Message- From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 24, 2001 3:09 PM To: '[EMAIL PROTECTED]' Subject: [PATCH] fix session caching Hi, The possible security fix that Geoff Thorpe had posted sometime back on the modssl-users mailing list (I can provide more details if required).. Index: ssl_engine_init.c === RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_init.c,v retrieving revision 1.11 diff -u -r1.11 ssl_engine_init.c --- ssl_engine_init.c 2001/08/24 04:08:04 1.11 +++ ssl_engine_init.c 2001/08/24 21:40:17 @@ -542,7 +542,8 @@ if (mc-nSessionCacheMode == SSL_SCMODE_NONE) SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); else -SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_SERVER); +SSL_CTX_set_session_cache_mode(ctx, +SSL_SESS_CACHE_SERVER | SSL_SESS_CACHE_NO_INTERNAL_LOOKUP); /* * Configure callbacks for SSL context
Re: MM
MM is gone from the tree. It is no longer necessary, APR provides it's own shared memory code. Ryan On Friday 24 August 2001 17:28, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: Quick Question - Is MM support still available and if yes, how do I enable it (--enable-sms ?) Thanks -Madhu -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: .libs/httpd
On Friday 24 August 2001 14:58, Greg Stein wrote: On Fri, Aug 24, 2001 at 02:42:30PM -0700, Ryan Bloom wrote: ... Because it is absolutely bogus that I have to choose whether EVERYTHING in the build is static or dynamic. I should be able to configure APR to be built as a static lib, but still have shared modules. Then you should have stopped the one libtool for everybody push. As long as we have a single libtool, and that thing is responsible for building static and/or dynamic outputs, then we can only build in the way specified by that one libtool. I completely disagree. I should be able to pass a set of flags to the libtool line, and have those flags determine how libtools works. That was how it worked when libtool and ltconfig were separate packages. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/include http_core.h
From: Greg Stein [EMAIL PROTECTED] Sent: Friday, August 24, 2001 4:51 PM On Fri, Aug 24, 2001 at 04:24:35PM -0500, William A. Rowe, Jr. wrote: ... I'm not approaching this again until I've slept on it. I have the patch essentially finished, adding a per-'dir' (proxy location, really) pattern of p, with a isregex flag of r. That's about as complicated as it gets. I'm not sure that I follow what the pattern thing is all about. Regex expressions, instead of strcmp matching. (E.g. ProxyMatch ) ... There will be no more 'faux' filenames. It's either an absolute path, or undefined (and irrelevant.) A few modules will get to deal with in anyways (such as mod_mime.) I'll start tommorow and wrap up tommorow, so everyone can take a look at what else this impacts. But getting rid of 'specials' is the only way to clean out directory_walk of all it's very heavy cruft. Note that r-filename and friends (finfo, canonical_filename, etc) are all related to the filesystem. As such, they are all completely bogus when you're talking about purely virtual resources (such as /server-status or content coming from a database). Thus, they should not be part of the request_rec, but instead part of a private structure to something like mod_filesystem. That mod_filesystem would implement the various translation and other fs-related items that occur. No argument here ;) This should work out pretty darned well, but I would argue everyone needs to be able to access the r-filename if their module works with 'files'. That doesn't mean every request needs an fs_request_rec member :) And no... I'm not suggesting this happen any time soon :-) But it will one day, if I can figure out how to tackle it and can set aside the time.
[PATCH] fix session caching
Hi, The possible security fix that Geoff Thorpe had posted sometime back on the modssl-users mailing list (I can provide more details if required).. Index: ssl_engine_init.c === RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_init.c,v retrieving revision 1.11 diff -u -r1.11 ssl_engine_init.c --- ssl_engine_init.c 2001/08/24 04:08:04 1.11 +++ ssl_engine_init.c 2001/08/24 21:40:17 @@ -542,7 +542,8 @@ if (mc-nSessionCacheMode == SSL_SCMODE_NONE) SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); else -SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_SERVER); +SSL_CTX_set_session_cache_mode(ctx, +SSL_SESS_CACHE_SERVER | SSL_SESS_CACHE_NO_INTERNAL_LOOKUP); /* * Configure callbacks for SSL context
Re: .libs/httpd
On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote: On Friday 24 August 2001 00:33, Greg Stein wrote: On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote: ... libuncooltool. i didn't realize libapr was now linked as a shared library. that explains everything. You could probably pass --disable-shared at Apache's config line. Of course, then *everything* would be built statically and you'd get a big ass blob of an executable :-) Please don't do that. Passing --disable-shared is what caused the shared modules to stop working. Apache should be able to work as one big monolithic executable. Shared modules should still be able to work because Apache would still have DSO loading capabilities. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [Fwd: brianp patch Quantify results] (was thread-specific freelistfor pools patch )
For the pools code, it can only be patched. It is unacceptable to toss a completely written-from-scratch replacement into the code base. If it takes a sequence of 20 patches to reach the written-from-scratch stage, then fine... but that means each step has been reviewable as you go along. Nonsense. If the new code is cleaner and shorter than the existing code for pools, diffs won't make it any easier to understand. Our process cannot be allowed to get in the way of fundamental improvements to the code base. Roy
recommanded configure for 2.0.24 ?
Also what's the recommanded ./configure params on Linux boxes ? I'm using the following which may be a little longer ./configure \ --with-mpm=threaded \ --enable-so \ --enable-env=shared \ --enable-setenvif=shared \ --enable-unique_id=shared \ --enable-mime=shared \ --enable-mime_magic=shared \ --enable-negotiation=shared \ --enable-alias=shared \ --enable-rewrite=shared \ --enable-userdir=shared \ --enable-speling=shared \ --enable-dir=shared \ --enable-autoindex=shared \ --enable-access=shared \ --enable-auth=shared \ --enable-auth_anon=shared \ --enable-auth_db=shared \ --enable-auth_dbm=shared \ --enable-auth_digest=shared \ --enable-headers=shared \ --enable-cern_meta=shared \ --enable-expires=shared \ --enable-asis=shared \ --enable-include=shared \ --enable-cgi=shared \ --enable-cgid=shared \ --enable-actions=shared \ --enable-status=shared \ --enable-info=shared \ --enable-log_config=shared \ --enable-usertrack=shared \ --enable-imap=shared \ --enable-mmap_static=shared \ --enable-dav=shared \ --enable-dav-fs=shared \ --enable-vhost-alias=shared \ --enable-echo=shared \ --enable-cache=shared \ --enable-suexec=shared \ --enable-ssl=shared \ --with-ssl=/usr May be the following is more recommanded ? ./configure \ --with-mpm=threaded \ --enable-so \ --enable-module=all \ --enable-mods-shared=all \ --enable-so \ --enable-ssl --with-ssl=/usr/include/ Thanks for your advice, AP 2.0 gurus
Re: .libs/httpd
On Friday 24 August 2001 13:51, Greg Stein wrote: On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote: On Friday 24 August 2001 00:33, Greg Stein wrote: On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote: ... libuncooltool. i didn't realize libapr was now linked as a shared library. that explains everything. You could probably pass --disable-shared at Apache's config line. Of course, then *everything* would be built statically and you'd get a big ass blob of an executable :-) Please don't do that. Passing --disable-shared is what caused the shared modules to stop working. Apache should be able to work as one big monolithic executable. Shared modules should still be able to work because Apache would still have DSO loading capabilities. But as I said, libtool sucks. Basically, libtool 1.4 has combined ltconfig and libtool into one executable. If you pass --disable-shared to the configure step, the libtool is built in such a way, that it can no longer create shared libraries. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On 25 Aug 2001 [EMAIL PROTECTED] wrote: rbb 01/08/24 22:26:05 Modified:.CHANGES modules/filters mod_include.c Log: Add the ability for mod_include to add the INCLUDES filter if the file is configured for the server-parsed handler. This makes the configuration for .shtml files much easier to understand, and allows mod_include to honor Apache 1.3 config files. Based on Doug MacEachern's patch to PHP to do the same thing. It still does not honor 1.3's magic text/x-server-parsed-html mime-type, though, right? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Friday 24 August 2001 22:41, Cliff Woolley wrote: On 25 Aug 2001 [EMAIL PROTECTED] wrote: rbb 01/08/24 22:26:05 Modified:.CHANGES modules/filters mod_include.c Log: Add the ability for mod_include to add the INCLUDES filter if the file is configured for the server-parsed handler. This makes the configuration for .shtml files much easier to understand, and allows mod_include to honor Apache 1.3 config files. Based on Doug MacEachern's patch to PHP to do the same thing. It still does not honor 1.3's magic text/x-server-parsed-html mime-type, though, right? No, but that would actually be trivial to add. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
