EOS bucket in RESOURCE filters
Is it possible that the RESOURCE filters don't get the EOS bucket? I'm working on filter examples which use context to maintain status/keep remainder data between filter invocations for the same request. For some reason I don't get the EOS bucket, so I don't know how to flush the data stored in the filter context. I do see EOS in CONNECTION filters. I've tried to look at the existing modules for an example, but I didn't find any RESOURCE filters that use the context. It seems that the existing RESOURCE filters can work just fine without the EOS bucket being sent through. Thanks. __ 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
[patch] Makefile.in
Is there any reason why mod_auth.h shouldn't be copied over during a 'make install' for 3rd party auth modules to use? Shane Index: Makefile.in === RCS file: /home/cvspublic/httpd-2.0/Makefile.in,v retrieving revision 1.127 diff -u -r1.127 Makefile.in --- Makefile.in 30 Sep 2002 15:34:40 - 1.127 +++ Makefile.in 10 Jan 2003 03:05:33 - @@ -169,6 +169,7 @@ cp -p $(srcdir)/os/$(OS_DIR)/os-inline.c $(DESTDIR)$(includedir); \ fi; @cp -p $(srcdir)/server/mpm/$(MPM_SUBDIR_NAME)/*.h $(DESTDIR)$(includedir) + @cp -p $(srcdir)/modules/aaa/mod_auth.h $(DESTDIR)$(includedir) @cp -p $(srcdir)/modules/dav/main/mod_dav.h $(DESTDIR)$(includedir) @cp -p $(srcdir)/modules/filters/mod_include.h $(DESTDIR)$(includedir) @cp -p $(srcdir)/modules/generators/mod_cgi.h $(DESTDIR)$(includedir)
Re: [patch] include/util_filter.h
Jeff Trawick wrote: Stas Bekman <[EMAIL PROTECTED]> writes: I don't know how hard it is to decide to commit an obvious API doc patch. Why does it always have to be reposted several times before it gets committed? As has been mentioned many times before on this list, if a patch isn't committed or commented on, you have to remind us. There are as many whys for this requirement as there are httpd committers trying to juggle multiple responsibilities. Consider us reminded, but not chastised. Many of us have been playing hookey through the holidays and have all manner of todos to catch up with. It's understandable. But it doesn't help to make other people want to contribute. The only reason I persist is because I work on mod_perl and mod_perl relies on httpd things, so I *need* things to be fixed (e.g. because we autogenerated docs from httpd header files in this particular case). Others who submit things they have noticed wrong, but don't really require a fix, move on, when their posts/patches are ignored, so the efforts are just getting lost. You are talking about httpd committers having "multiple responsibilities", but I think you really mean "multiple itches to scratch". Perhaps the httpd project could benefit from having a pumpkin, similar to what Perl and several other projects have, where in addition to various cool folks scratching their itches at their own pace, there is that one person who has a real responsibility. And who's is responsible for doing it all (the back-bone), including things that others don't find sexy. Since this job requires a lot of time and dedication, a person performs a pumpkin's role only for certain periods of time (usually using release versions as time boundaries). If that was the case, things (especially simple ones like my patch) won't fall between chairs, leading to more inspiration from users to help. __ 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: [PATCH] Avoid busy wait in winnt MPM when all workers are busy
Thanks, I'll review the patch but it will probably be sometime next week. Bill > -Original Message- > From: Igor Nazarenko [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 08, 2003 4:05 PM > To: [EMAIL PROTECTED] > Subject: [PATCH] Avoid busy wait in winnt MPM when all workers are busy > > > The only modification is in > ./server/mpm/winnt/child.c > > That file hasn't changed between 2.0 and 2.1 > > This is the first time I'm submitting a patch so please tell me if I'm doing > something wrong. > > Igor > > _ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail >
Re: cvs commit: httpd-2.0 CHANGES configure.in
--On Thursday, January 09, 2003 16:51:54 -0500 Greg Ames <[EMAIL PROTECTED]> wrote: more weirdness. I'm trying to verify that there is some way to get Apache to build with apr & apr-util preinstalled outside of httpd. So far I've seen: * apr-util's configure dies with configure: error: cannot find install-sh or install.sh in ../apr/build ./../apr/build ...if the apr source tree isn't called "apr" exactly or doesn't share a commom parent with the apr-util source tree. OK, I can shuffle things around to get past that pretty easily. Moving on, apr-util can not build without apr being in ../apr. We know this has to be fixed before we can even consider releasing apr-util as a standalone. 0.9.2 was stillborn because of this. * apr-util's make dies with Makefile:23: /tmp/inst_apr/bin/build/rules.mk: No such file or directory make: *** No rule to make target `/tmp/inst_apr/bin/build/rules.mk'. Stop. hmmm, looks like apr-util's ./configure --help is telling a fib when it says --with-apr can point to apr's install directory. It can't, but seems to work OK if you point it at apr's source tree. It can. My guess is that you have a symlink somewhere. apr-config can get confused in certain circumstances when there is a symlink so that the prefix that was originally passed to apr-config is invalid. It thinks it is not in the source nor installed directory - therefore, it assumes it is in a VPATH situation. This results in the bin/ weirdness. There are some recent fixes in apr that attempt to address this (but doesn't work everywhere since it relies upon 'realpath' being available). * httpd's make dies when trying to generate exports.c, as Jeff reported, with gawk: /home/gregames/apache/httpd-2.0.44.pre1.no_apr/build/make_exports.awk:138 : (FILENAME=/home/gregames/apache/httpd-2.0.44.pre1.no_apr/os/unix/unixd.h FNR=141) fatal: cannot open file `/home/gregames/apache/httpd-2.0.44.pre1.no_apr/srclib/apr/include/*.h' for reading (No such file or directory) My apr install directory is /tmp/inst_apr, so it does have the characters "apr" in its name. APR_INCLUDEDIR=`$apr_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^ ]]*\).*$|\1|'` You have to get the above sed rule from httpd-2.0's configure.in to fire correctly. It's very fragile and very wrong, but it works in some predictable edge cases. I haven't had the time to figure out exactly what the edge case is other than that apr-0.9.2 seems to work. Perhaps it is something to do with apr being at the end of the directory name? I want to add a --includedir option to apr-config so that we can eliminate the guessing we have right now. -- justin
Re: cvs commit: httpd-2.0/server/mpm/worker fdqueue.c
Brian Pane wrote: Greg Ames wrote: apr_atomic_dec? That does return something. The problem is that, since we have to use apr_atomic_cas for the increment (due to the lack of a return value on apr_atomic_inc), we can't use apr_atomic_dec on the same variable. apr_atomic_cas works on apr_uint32_t, while apr_atomic_dec works on apr_atomic_t. If we could change the apr_atomic_inc/dec functions to use apr_uint32_t, this part of the fdqueue code could become a lot simpler. I am certainly in favor of changing apr_atomic_inc/dec so they can be useful. I'm wondering if it's ok to use an ordinary apr type, like apr_uint32_t? or do we need special atomic types marked as volatile or memory-resident or whatever so that gcc won't assign them to registers or optimize them out or ??? I don't know the answer, but have seen kernel code do such things (OK Jeff, I've been infected by the GPL...no hope for me). I still have one more change I'm hoping to make in the fdqueue synchronization logic: move the queue manipulation code in ap_queue_push/pop outside the mutex protected region by maintaining a linked list of queue nodes with apr_atomic_casptr. Sounds good, as long as the pops are single threaded somehow, or if you have some other way of getting around the A-B-A cas pop window. Greg
Re: cvs commit: httpd-2.0 CHANGES configure.in
Justin Erenkrantz wrote: --On Wednesday, January 8, 2003 7:54 AM -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: As I posted yesterday, generation of exports.c is busted without srclib/apr and srclib/apr-util. If you can get it to work with just the buildconf change, I'd love to see it. Well, it doesn't work if you don't call your APR install apr. If it's called apr-0.9.2, it works. If it's called, say, httpd-2.0.44-dev, it won't work. more weirdness. I'm trying to verify that there is some way to get Apache to build with apr & apr-util preinstalled outside of httpd. So far I've seen: * apr-util's configure dies with configure: error: cannot find install-sh or install.sh in ../apr/build ./../apr/build ...if the apr source tree isn't called "apr" exactly or doesn't share a commom parent with the apr-util source tree. OK, I can shuffle things around to get past that pretty easily. Moving on, * apr-util's make dies with Makefile:23: /tmp/inst_apr/bin/build/rules.mk: No such file or directory make: *** No rule to make target `/tmp/inst_apr/bin/build/rules.mk'. Stop. hmmm, looks like apr-util's ./configure --help is telling a fib when it says --with-apr can point to apr's install directory. It can't, but seems to work OK if you point it at apr's source tree. * httpd's make dies when trying to generate exports.c, as Jeff reported, with gawk: /home/gregames/apache/httpd-2.0.44.pre1.no_apr/build/make_exports.awk:138: (FILENAME=/home/gregames/apache/httpd-2.0.44.pre1.no_apr/os/unix/unixd.h FNR=141) fatal: cannot open file `/home/gregames/apache/httpd-2.0.44.pre1.no_apr/srclib/apr/include/*.h' for reading (No such file or directory) My apr install directory is /tmp/inst_apr, so it does have the characters "apr" in its name. Greg
Re: cvs commit: httpd-2.0 CHANGES configure.in
--On Thursday, January 9, 2003 11:07 AM -0500 Greg Ames <[EMAIL PROTECTED]> wrote: just to be sure everybody is on the same page, is there a srclib/apr[-util]/ under httpd in the test above at any point? Only when buildconf is run. The resulting tarball should not require srclib/apr[-util]. We will package it in our release, but cool people can figure out they don't need that. I would expect it might help package maintainers considerably. -- justin
[PATCH] Columnar character test table output.
This is a really minor thing, but this patch has been helpful to me
while debugging some stuff today. Negligible cost, profitable gain,
yes?
--
* httpd-2.0/server/gen_test_char.c
(main): Ensure columnar output of character test table data, and
wrap lines at every 16 items instead of 20.
Index: server/gen_test_char.c
===
RCS file: /home/cvspublic/httpd-2.0/server/gen_test_char.c,v
retrieving revision 1.14
diff -u -r1.14 gen_test_char.c
--- server/gen_test_char.c 9 Apr 2002 11:12:10 - 1.14
+++ server/gen_test_char.c 9 Jan 2003 17:54:45 -
@@ -87,7 +87,7 @@
"#define T_HTTP_TOKEN_STOP (%u)\n"
"\n"
"static const unsigned char test_char_table[256] = {\n"
- "0,",
+ " 0,",
T_ESCAPE_SHELL_CMD,
T_ESCAPE_PATH_SEGMENT,
T_OS_ESCAPE_PATH,
@@ -98,7 +98,7 @@
for (c = 1; c < 256; ++c) {
flags = 0;
-if (c % 20 == 0)
+if (c % 16 == 0)
printf("\n");
/* escape_shell_cmd */
@@ -135,7 +135,7 @@
flags |= T_HTTP_TOKEN_STOP;
}
-printf("%u%c", flags, (c < 255) ? ',' : ' ');
+printf("%3u%c", flags, (c < 255) ? ',' : ' ');
}
Re: Showstopper ... was: Tagged the tree
William A. Rowe, Jr. wrote: >For something completely different, once this is released, we are stuck >with the api... > >#define APR_FILEPATH_ENCODING_UNKNOWN 0 >#define APR_FILEPATH_ENCODING_LOCALE 1 >#define APR_FILEPATH_ENCODING_UTF8 2 >APR_DECLARE(apr_status_t) apr_filepath_encoding(int *style, apr_pool_t *p); > >Why not drop the enum and use an apr_filepath_encoding that returns >an actual codepage name? Then the ambiguity of _LOCALE disappears. > >Put another way, either APR_FILEPATH_ENCODING_LOCALE >with a locale of utf-8 or the APR_FILEPATH_ENCODING_UTF8 can >mean the same thing. This seems wrong. > It's not. you get _UTF8 only when _UTF8 is _not_ the same as _LOCALE > For that matter, it might >also be APR_FILEPATH_UNKNOWN if we didn't determine it. > I don't really expect any implementation fo apr_filepath_encoding to return _UNKNOWN; it's there for completeness. If there is such an implementation, it probably also can't implement apr_os_locale_encoding and falls back on apr_os_default_encoding -- meaning "I don't know." >Just asking for such things to be as clean as we can ask before we roll. > > I spent much time and though (and discussion) wondering about this same issue. I decided to do it this way because we already have functions that return the name of the locale encoding, which apps can use if necessary. An application really only has to know the difference between _LOCALE and _UTF8, and convert accordingly; it doesn't necessarily have to know the actual name of the encoding, so calling apr_os_locale_encoding from apr_filepath_encoding is just a waste of cycles, and so is "strcmp(foo,"UTF-8")" instead of (foo==APR_FILEPATH_ENCODING_UTF8). -- Brane Čibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
[PATCH] A bug in table adjust function that causes a core dump (fwd)
Can anyone comment on this? --Cliff -- Forwarded message -- Date: Thu, 09 Jan 2003 13:48:59 +0100 From: Bernd Steinert <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [PATCH] A bug in table adjust function that causes a core dump On Thursday, 5 December 2002, Cliff Wooley replied: > On Thu, 5 Dec 2002, Bernd Steinert wrote: > > > on November 11 Kirill Shirkov reported a bug in the table_adjust function > > that causes core dumps. He described how the core dumps can be reproduced. > > Some colleague of mine confirmed this behaviour. > > I must have missed the patch... can someone repost it for me (and CC: me > and Ralf on it), and put [PATCH] at the beginning of the subject line of > the message. Thanks a lot Cliff for the immediatereply. (unfortunaltely I missed it before going on holidays.) Here is what Kirill Shirkov wrote on Friday, November 11, 2002 --- his fix is at the end: > Hi folks, > > I have found a bug in table_adjust function, and I haven't seen any reports about > this error in the mailing list. Also, this error is not fixed in the current version > of mod_ssl (2.8.12). > > THE BUG > - > > ssl_util_table.c file, line 1755: > > buckets = (table_entry_t **) table_p->ta_calloc(buck_n, sizeof(table_entry_t *)); > if (table_p->ta_buckets == NULL) > return TABLE_ERROR_ALLOC; > > buckets variable is not checked here and this causes a coredump when the table size > is big and there is no memory for reallocating the buckets. Below is a stack dump > from Solaris 8 running Apache 1.3.26 + mod_ssl 2.8.10 + OpenSSL 0.9.6g: > > ... > --- called from signal handler with signal 11 (SIGSEGV) --- > 00089b60 table_adjust (0, fe0a09cc, fe09ea84, 0, 3e9, fe08cdd8) + d0 > 00081cac ssl_scache_shmht_expire (1, 20, fe0e436c, 4, 31, fe08e438) + 130 > 00081a24 ssl_scache_shmht_store (94, 18aef0, 20, bb8200, bb81b8, 1ad4e0) + 11c > 0007b7e0 ssl_callback_NewSessionCacheEntry (bb8200, 3dc42bfb, 7b784, 1ad4e0, bb81b8, ba65e0) + 5c > fe64c584 ssl_update_cache (a1c458, 2, 21c1, 1ad4e0, 1, a1c458) + a8 > fe63ef14 ssl3_accept (a1c458, 2100, 21c0, 3004, 90, 0) + 8c8 > fe64d520 SSL_accept (a1c458, fe63e64c, 1, ba1088, 10, ba109a) + 24 > fe648d94 ssl23_get_client_hello (2a, 70, 2, ffbef100, 1, a1c458) + 7cc > fe648528 ssl23_accept (a1c458, fe648388, 1a1f70, 0, 6f757400, 6f757400) + 1a0 > fe64d520 SSL_accept (a1c458, 79d30, 12c, 0, 16fab0, 17cee0) + 24 > 00079730 ssl_hook_NewConnection (908cc0, 178000, 1781d0, ffbef2cc, 16fa34, 806478) + 2b4 > 0004c4a0 new_connection (163b1c, 45415049, 908cc0, ffbef344, ffbef344, 3) + 114 > 0004d470 child_main (173400, 173400, 173400, ff36b228, ff365958, ff35efb8) + 634 > ... > > HOW TO REPRODUCE > -- > > I was able to reproduce the error in the following way: > > 1. Set SSLSessionCacheTimeout to 20 minutes > 2. Set SSLSessionCache size to 1024000 (or a value that is close to your EAPI_MM_CORE_MAXSIZE). > 3. Set ExtendedStatus to On > 4. Start the server and run a script like the following one: > > #!/usr/local/bin/bash > > i=0 > while expr $i \< 400 >/dev/null; do > echo $i > i=`expr $i + 1` > > for j in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do > curl -I https://your.host/ & > done > sleep 1 > done > > BTW, you may interrupt the script when the "current sessions" parameter at the bottom > of the server status page (https://your.host/server-status) have stopped growing. > > 5. Wait 25 minutes from the time you have started the script and reload the server > status page or access the server over SSL. Most likely you will see a core dump. > > THE FIX > > > If we change the if statement like this:.. > > if (table_p->ta_buckets == NULL || buckets == NULL) > return TABLE_ERROR_ALLOC; > > ...the server doesn't dump core in the test. > > Another solution to this problem is to decrease shared memory size in the config file. > > Best regards, > Kirill Shirokov, > St. Petersburg, Russia. --- Dr. Bernd Steinert kippdata GmbH Tel.: 0228 - 9 85 49 0 Bornheimer Str. 33a Fax: 0228 - 9 85 49 50 D-53111 BonneMail: [EMAIL PROTECTED]
Re: cvs commit: httpd-2.0 CHANGES configure.in
Justin Erenkrantz wrote: --On Wednesday, January 8, 2003 9:43 AM -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: I'm sorry for being dense, but please clarify: What patch do you suggest to apply to STRIKER_2_0_44_PRE2, and will the following then work? httpd-2.0/buildconf r1.29. Then, the configure.in patch that was committed should be reverted. (first install apr and apr-util into /tmp/aprinst) ./buildconf ./configure --with-apr=/tmp/aprinst --with-apr-util=/tmp/aprinst --other-opts make make install Yes - it does here. -- justin just to be sure everybody is on the same page, is there a srclib/apr[-util]/ under httpd in the test above at any point? Greg
Re: Showstopper ... was: Tagged the tree
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > At 07:00 PM 1/7/2003, you wrote: > >Sander Striker wrote: > > > >>Hi, > >> > >>I tagged the tree with STRIKER_2_0_44_PRE2. The tag consists > >>of APACHE_2_0_BRANCH and apr/apr-util HEAD. If you feel that > >>something should not be in here, please let me know ASAP. > > > >What about the change in argument types for the APR queue > >and hash API? That's the one thing I know of that would > >break binary compatibility. yuck... move Sander's tag back or back out the change to APR until the window just prior to 1.0? > Beyond the queue and hash changes that break on all 64 bit platforms > (and should be reverted and deferred to APR 1.0), here are some other > interesting bits... > > APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf, > -int length); > +apr_size_t length); > > won't pose a problem except on 64 bit LP and P platforms... on those > few (Win64/AIX/dunno which others) it should be postponed for the > APR 1.0 release (targeted by httpd-2.2.) same comment as above > For something completely different, once this is released, we are stuck > with the api... through the 0.9.x series -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [patch] include/util_filter.h
Stas Bekman <[EMAIL PROTECTED]> writes: > I don't know how hard it is to decide to commit an obvious API doc > patch. Why does it always have to be reposted several times before it > gets committed? As has been mentioned many times before on this list, if a patch isn't committed or commented on, you have to remind us. There are as many whys for this requirement as there are httpd committers trying to juggle multiple responsibilities. Consider us reminded, but not chastised. Many of us have been playing hookey through the holidays and have all manner of todos to catch up with. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
[patch] src/support/suexec.c (php as cgi)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You might want to commit this little patch to suexec.c. When using PHP as CGI in a mass hosting environment, it is very useful to specify different php.ini configuration files per virtual host (SetEnv PHPRC /path/to/customer) This patch allows suexec to pass the PHPRC variable to the PHP binary. - --- src/support/suexec-old.c2003-01-09 10:27:47.0 +0100 +++ src/support/suexec.c2002-10-10 16:54:01.0 +0200 @@ -165,6 +165,7 @@ "UNIQUE_ID", "USER_NAME", "TZ", +"PHPRC", NULL }; - -- Andreas Kerber (Systemadministration - Internet Solutions) [EMAIL PROTECTED] - -- fon +49 (0)831 54058 100 fax +49 (0)831 54058 499 - -- SpeedKom GmbH (HRB 6359) Netzwerk & Internet-Loesungen Unterwanger Str 3 * D-87439 Kempten (Allgaeu) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: SpeedKOM GmbH - http://www.speedkom.net iD8DBQE+HUM/ONsWRXzZM3sRAg1vAJwPDrj8ieG16IrsK1AIXECuO4hrQACg0zbN dSB9jSgvxzhObjS1KPwD3cU= =nDrx -END PGP SIGNATURE-
Re: [dwmalone@maths.tcd.ie: Quick apapche patch.]
--On Thursday, January 9, 2003 5:05 AM + Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: --- /src/info-systems/httpd-2.0.43/server/listen.c.orig Tue Jan 7 16:13:53 2003 +++ /src/info-systems/httpd-2.0.43/server/listen.c Tue Jan 7 16:16:09 2003 @@ -184,7 +184,13 @@ #if APR_HAS_SO_ACCEPTFILTER #ifndef ACCEPT_FILTER_NAME +#define ACCEPT_FILTER_NAME "httpready" +#ifdef __FreeBSD_version +#if __FreeBSD_version < 411000 /* httpready broken before 4.1.1 */ +#undef ACCEPT_FILTER_NAME #define ACCEPT_FILTER_NAME "dataready" +#endif +#endif #endif apr_socket_accept_filter(s, ACCEPT_FILTER_NAME, ""); #endif Wouldn't this make more sense as an autoconf test? I don't really have access to a FreeBSD machine, but certainly this seems like something we could check/define at configure-time rather than cluttering up the code with more #define's. -- justin
[dwmalone@maths.tcd.ie: Quick apapche patch.]
heads up on the inconsistency :) - Forwarded message from David Malone <[EMAIL PROTECTED]> - Delivery-date: Tue, 07 Jan 2003 16:47:43 + To: [EMAIL PROTECTED] Subject: Quick apache patch. From: David Malone <[EMAIL PROTECTED]> In Apache 1.3 the accept filter name for recent versions of FreeBSD is set to "httpready" and for older versions it is set to "dataready". In Apache 2.0 it always seems to be set to "dataready" - I've been binary-editing my Apache compiles to change it, but the patch below would make Apache 2.0 do the same thing as Apache 1.3. (If you want to inspect the code in 1.3, it is in src/main/http_main.c, search for ACCEPT_FILTER_NAME). David. --- /src/info-systems/httpd-2.0.43/server/listen.c.orig Tue Jan 7 16:13:53 2003 +++ /src/info-systems/httpd-2.0.43/server/listen.c Tue Jan 7 16:16:09 2003 @@ -184,7 +184,13 @@ #if APR_HAS_SO_ACCEPTFILTER #ifndef ACCEPT_FILTER_NAME +#define ACCEPT_FILTER_NAME "httpready" +#ifdef __FreeBSD_version +#if __FreeBSD_version < 411000 /* httpready broken before 4.1.1 */ +#undef ACCEPT_FILTER_NAME #define ACCEPT_FILTER_NAME "dataready" +#endif +#endif #endif apr_socket_accept_filter(s, ACCEPT_FILTER_NAME, ""); #endif - End forwarded message - -- Colm MacCárthaigh / HEAnet, Brooklawn House, / Network Engineer +353 1 6609040/ Shelbourne Road, Dublin, IE / http://www.hea.net/
