[STATUS] (perl-framework) Wed Feb 26 23:45:25 EST 2003
httpd-test/perl-framework STATUS: -*-text-*- Last modified at [$Date: 2002/03/09 05:22:48 $] Stuff to do: * finish the t/TEST exit code issue (ORed with 0x2C if framework failed) * change existing tests that frob the DocumentRoot (e.g., t/modules/access.t) to *not* do that; instead, have Makefile.PL prepare appropriate subdirectory configs for them. Why? So t/TEST can be used to test a remote server. * problems with -d perl mode, doesn't work as documented Message-ID: [EMAIL PROTECTED] Date: Sat, 20 Oct 2001 12:58:33 +0800 Subject: Re: perldb Tests to be written: * t/apache - simulations of network failures (incomplete POST bodies, chunked and unchunked; missing POST bodies; slooow client connexions, such as taking 1 minute to send 1KiB; ...) * t/modules/autoindex - something seems possibly broken with inheritance on 2.0 * t/ssl - SSLPassPhraseDialog exec: - SSLRandomSeed exec:
Re: auth_ldap authentication as user
i had some trouble to bring auth_ldap to work. I solved the problems but not to my complete satisfaction. The reason for this is the way auth_ldap does the authentication with the ldap server. Here the sequence of operations auth_ldap does in a default ldap setup. In this setup anyone has read access to all data (except passwords) of the directory. Use the AuthLDAPBindDN and AuthLDAPBindPassword directives to solve this. Details are in the manual. I do. Can you please reread my previous post. That is not the problem. The problem is that for the first user auth_ldap binds as admin with the binddn and the bindpassword provided in the httpd.conf. But then auth_ldap binds as the user that has authenticated. The problem is that this user may not have enough previleges to do further searches. But auth_ldap uses searches as part of the authentication process. Regards, Sebastian
Unresolved symbols: MAKELONG and SetLastError
Hi! I'm pretty sure I've seen something about this on the list, but I can't seem to find the threads now. And it might be me doing something wrong ;) /bin/sh /php/apr/libtool --silent --mode=compile cc -g -pthread-DOSF1 -I/php/apr/include -I/php/apr-util/include -I/php/apr-util/xml/expat/lib -I. -I/php/httpd-2.0/os/unix -I/php/httpd-2.0/server/mpm/prefork -I/php/httpd-2.0/modules/http -I/php/httpd-2.0/modules/filters -I/php/httpd-2.0/modules/proxy -I/php/httpd-2.0/include -I/usr/local/include -I/php/httpd-2.0/modules/dav/main -prefer-non-pic -static -c modules.c touch modules.lo /bin/sh /php/apr/libtool --silent --mode=link cc -g -pthread-DOSF1 -I/php/apr/include -I/php/apr-util/include -I/php/apr-util/xml/expat/lib -I. -I/php/httpd-2.0/os/unix -I/php/httpd-2.0/server/mpm/prefork -I/php/httpd-2.0/modules/http -I/php/httpd-2.0/modules/filters -I/php/httpd-2.0/modules/proxy -I/php/httpd-2.0/include -I/usr/local/include -I/php/httpd-2.0/modules/dav/main -export-dynamic -L/php/apr-util/xml/expat/lib -L/usr/local/lib -o httpd modules.lo modules/aaa/mod_access.la modules/aaa/mod_auth.la modules/arch/win32/mod_isapi.la modules/experimental/mod_cache.la modules/experimental/mod_mem_cache.la modules/filters/mod_include.la modules/filters/mod_deflate.la modules/loggers/mod_log_config.la modules/metadata/mod_env.la modules/metadata/mod_expires.la modules/metadata/mod_headers.la modules/metadata/mod_usertrack.la modules/metadata/mod_unique_id.la modules/metadata/mod_setenvif.la modules/http/mod_http.la modules/http/mod_mime.la modules/generators/mod_status.la modules/generators/mod_autoindex.la modules/generators/mod_asis.la modules/generators/mod_cgi.la modules/mappers/mod_negotiation.la modules/mappers/mod_dir.la modules/mappers/mod_imap.la modules/mappers/mod_actions.la modules/mappers/mod_userdir.la modules/mappers/mod_alias.la modules/mappers/mod_rewrite.la modules/mappers/mod_so.la server/mpm/prefork/libprefork.la server/libmain.la os/unix/libos.la -lz /php/httpd-2.0/srclib/pcre/libpcre.la /php/apr-util/libaprutil-0.la /php/apr-util/xml/expat/lib/libexpat.la -liconv /php/apr/libapr-0.la -lm -lresolv ld: Unresolved: MAKELONG SetLastError gmake[1]: *** [httpd] Error 1 gmake[1]: Leaving directory `/php/httpd-2.0' gmake: *** [all-recursive] Error 1 This is on Tru64 5.1 and httpd 2.0-dev. Autoconf 2.13, automake 1.5, libtool 1.4.3, GNU m4 1.4 / Magnus Määttä
Re: cvs commit: httpd-2.0 CHANGES
Greg Stein wrote: On Wed, Feb 26, 2003 at 05:10:12PM -0800, Justin Erenkrantz wrote: --On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman wrote: So if absolutely anything added to the dev branch must have a vote for before merging back to the stable branch, I stand corrected and will make sure that this won't happen again in the future. I thought that the common sense should be applied when judging what can be backported without the vote. Heh. The entire reason for the vote is to prevent 'common sense' from interfering with the stability of the tree. -- justin Bah. That's insanity. A bug fix is a bug fix. We never took votes for bug fixes for 1.3, and I see no reason to start now. Please go update STATUS with your vote on how this should be handled (the R-T-C vs. C-T-R vote). I think some folks may not be happy with the current philosophy but haven't made their feelings known formally. If you aren't happy with the current choices, add one.
Re: Apache 2.0.44 w/ auth_ldap build errors
Cliff Woolley wrote: If you go into the apr-util directory and run ./configure --help, among other things it will tell you: --with-ldap-include=path path to ldap include files with trailing slash --with-ldap-lib=pathpath to ldap lib file --with-ldap=library ldap library to use random note: it would be useful if ./configure --help for Apache would also display apr and apr-util --help screen if the Apache configure is going to configure apr and apr-util as well I've noticed a PR or two that could have been prevented by this
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: gstein 2003/02/27 04:53:19 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: trawick wanted commentary in STATUS rather than on the mailing list. fine... I don't care whether commentary on this topic is in STATUS or on the mailing list (I for one put all of my commentary on this topic on the mailing list). I do want to make sure that people who appear to disagree with the status quo take the opportunity to formalize that with a vote, because it is that vote that directly controls how things are done, not the megabytes of commentary. Regarding your comment But now we're seeing this stupid R-T-C hammer being used to smack developers over the head. Stas didn't follow the rules that the group chose, and I took exception because his action interfered with my own desires to carefully review anything within my grasp which is committed to the stable branch. End of story. [IMO he didn't follow the rules not because he was bad and needed to be smacked over the head but because he was not accustomed to how the stable branch was being handled and needed to be steered in the right direction. I'm definitely in the Stas fan club and don't plan on trying to smack him over the head. I also have faith that he is clever enough to realize that procedural comments on a commit (be they gripes about whitespace or missing information or otherwise) are not smacks on the head but instead attempts to steer somebody in the right direction.]
PR 17462: let mod_rewrite hard limit its internal redirects
I'd guess this has bitten a lot of people. There are several cases, in
which mod_rewrite runs into a deadloop of internal redirects.
I think, we can fix it by counting the times the fixup hook effectively
works (regardless of equality of the uris) and stop after a configurable
limit, e.g.
RewriteOptions MaxRedirects=x
where x defaults to 10 or so.
mod_rewrite could store that value in r-request_config. If it's exceeded,
a config error is assumed and an error logged. The response should be 500
then.
WDYT?
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=map{chr(ord( # André Malo ;
$_)-1)}split//=$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
Re: cvs commit: httpd-2.0/server connection.c
William A. Rowe, Jr. wrote: They should, ap_run_pre_connection is an Apache hook. Yes, it returns an int, so the only change here should be -apr_status_t rc; +int rc; We aren't calling apr_ function here, and hooks always allow OK, DONE, or (result). ahh, that's the missing piece of commentary on Stas' commit to explain various confusion :)
Re: PR 17462: let mod_rewrite hard limit its internal redirects
On Thu, Feb 27, 2003 at 03:07:31PM +0100, André Malo wrote: I'd guess this has bitten a lot of people. There are several cases, in which mod_rewrite runs into a deadloop of internal redirects. I think, we can fix it by counting the times the fixup hook effectively works (regardless of equality of the uris) and stop after a configurable limit, e.g. RewriteOptions MaxRedirects=x where x defaults to 10 or so. mod_rewrite could store that value in r-request_config. If it's exceeded, a config error is assumed and an error logged. The response should be 500 then. WDYT? Generally I like the idea, but I'm a bit wary about setting a default value other than unlimited because it could break existing configs. The other thing I'm not quite sure about is how you would make this work for rules in .htaccess? (but I may be missing something) vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: cvs commit: httpd-2.0 CHANGES
Justin Erenkrantz wrote: --On Wednesday, February 26, 2003 7:55 PM -0800 Greg Stein [EMAIL PROTECTED] wrote: And remember: this *is* source control. If somebody commits a bug fix and people want to shoot it down, then we can revert it. But assuming correctness and committing the fix is hella better than gating every single little change. We have lazy consensus on the unstable tree (2.1). I agree with you 100% in the context of httpd-2.1 - go commit first - break the tree - we can revert changes easily as we have no expectations of stability there. But, I don't trust anyone's 'common sense' to know whether the most trivial fix broke anything or whether a bug fix is 'right.' Yes, it means gating changes on stable (2.0), but that's a price I'm willing to see us pay. I'd hope our code quality and stability improves because of that. -- justin Well said, Justin. Most of us have committed bug fixes with the best of intentions which were not quite complete or had unintended side effects. I certainly have - the deferred write pool stuff in core_output_filter comes to mind. Letting the fixes age a bit in the unstable tree reduces the probability of unpleasant surprises happening in the stable tree, at least for mainline code. We can be extra diligent about reviewing/testing changes that we know are not mainline. Greg
Re: cvs commit: httpd-2.0 CHANGES
Greg Stein wrote: On Wed, Feb 26, 2003 at 05:10:12PM -0800, Justin Erenkrantz wrote: --On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman [EMAIL PROTECTED] wrote: So if absolutely anything added to the dev branch must have a vote for before merging back to the stable branch, I stand corrected and will make sure that this won't happen again in the future. I thought that the common sense should be applied when judging what can be backported without the vote. Heh. The entire reason for the vote is to prevent 'common sense' from interfering with the stability of the tree. -- justin Bah. That's insanity. A bug fix is a bug fix. We never took votes for bug fixes for 1.3, and I see no reason to start now. Feature changes? Sure, we voted for those. Seriously, people. If there is a bug, then it should be fixed no matter where it lies. Sure, there can be some waffling based on *how* a bug is fixed, and hopefully people will know when to ask. What's the problem with fixing a bug. Really? We've had problems in the past with folks rewriting major portions of the server to fix relatively insignificant bugs and breaking major function across several releases as a result. The rewrites were generally NOT posted as a patch on the dev list prior to being committed and that is the real problem (ie, I can deal with a patch that is not quite right the first go'round provided folks were give an opportunity to review it before it goes in). Once code is committed, it is a difficult to get it out without bruising egos and causing waves of bad mojo. Been there, done that and threw away the snow globe. I am not going to cite examples so don't ask because it's not productive to go digging in the past. Bill
Re: cvs commit: httpd-2.0 CHANGES
Greg Ames wrote: mind. Letting the fixes age a bit in the unstable tree reduces the probability of unpleasant surprises happening in the stable tree, at least for mainline code. We can be extra diligent about reviewing/testing changes that we know are not mainline. Note that for me and perhaps others, the philosophy you just mentioned is not something I would vote for under any forseeable circumstances.
Re: cvs commit: httpd-2.0 STATUS
[EMAIL PROTECTED] wrote: + + Yes, I'm ranting, and hey, I'm even sober. :-) =:o -- === 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
Trust and Review was Re: cvs commit: httpd-2.0 STATUS
--On Thursday, February 27, 2003 12:53 PM + [EMAIL PROTECTED] wrote: + The problem here is that R-T-C expresses a fundamental + DISTRUST of your peers. We had problems stabilizing the + code simply because there are numerous interests in the + codebase, and those are not fully compatible. With the It's also the fact that I have no way of knowing whether my fix is perfect - I might think it is, but I just won't stake my reputation or this group's reputation on it. Actively enforcing peer review allows some confidence that at least two other people agree with the change. It's a way of backchecking not as a matter of distrust. In fact, I'd say it is the reverse: R-T-C mandates a trust in your peers that they are able and willing to understand the code. Creating code in isolation without anyone else understanding it is harmful. We're developing this server together. We have a number of places in our code that there may only be one or two people who fully understand it. I don't believe that is goodness on our parts. If we enforce code review, then it makes it such that others start to get exposed to other areas they may not have been exposed to before. That is the best way we can deal with people leaving and abandoning 'their' code. Even the most trivial 'common sense' commits can generate essential feedback that a single developer overlooked. I can only perform limited testing on it with my own platforms, compilers, etc. I may be too close to the problem to get an accurate view of what the fix should be. I view peer review as a safeguard and a mechanism to show the community that we are doing our best to produce the highest-quality releases that we can. The fact is that with C-T-R, we hardly ever did R. The sheer volume of commits was just too much for lots of developers - AIUI, this is why we abandoned R-T-C not because anyone in the Apache Group wanted to. If we all weren't so damn lazy, C-T-R might have worked in producing stable releases. I just don't believe that materialzed. Our release quality has been reducing for a long-time because we haven't been relying on what made us good: 'high-quality well-tested releases.' -- justin
Re: PR 17462: let mod_rewrite hard limit its internal redirects
* Mads Toftum wrote: On Thu, Feb 27, 2003 at 03:07:31PM +0100, André Malo wrote: RewriteOptions MaxRedirects=x where x defaults to 10 or so. mod_rewrite could store that value in r-request_config. If it's exceeded, a config error is assumed and an error logged. The response should be 500 then. Generally I like the idea, but I'm a bit wary about setting a default value other than unlimited because it could break existing configs. hmm, the idea behind is actually to break the configs (anyway) to prevent the server from crashing. 10 internal redirects are already a lot ones. But however, we could let it default to, 20, 50 or 100. I don't believe that such a high value would break any config (it's probably already broken then ...). YMMV. Some more opinions about that point are welcome. The other thing I'm not quite sure about is how you would make this work for rules in .htaccess? (but I may be missing something) It's actually only interesting for .htaccess files (resp. directory context). Because the rules there are handled in the fixup hook (+ redirect-handler) which causes mostly internal redirects. In server context the rules are handled in the translate_name hook and don't issue an internal redirect. So, to be more exact, the implementation would be: mod_rewrite counts every time it runs the redirect-handler and after $limit it refuses to run it again with a 500 + errorlog entry. Breaking existing configs with a limit of, for instance, 10 would mean, you have .htaccess(!)-configs that let the server run ten times into a rule that issues an internal redirect to elsewhere. While processing _one_ request - wow! nd -- kann mir jemand sagen, was genau @-Domains sind? Ein Mythos. Ein Werbetrick. Verarsche. Nenn es wie du willst... -- Alexandra Buss und Björn Höhrmann in dciwam
Re: Apache 2.0.44 w/ auth_ldap build errors
Cliff Woolley wrote: On Wed, 26 Feb 2003, Trevor Hurst wrote: Because when I run the make I get the following errors: -static -c mod_auth_ldap.c touch mod_auth_ldap.lo mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to have LDAP support built in If you go into the apr-util directory and run ./configure --help, among other things it will tell you: --with-ldap-include=path path to ldap include files with trailing slash --with-ldap-lib=pathpath to ldap lib file --with-ldap=library ldap library to use Go back to the top-level Apache directory and pass ./configure these arguments, and it will pass them through to apr-util for you. I admit this is not entirely obvious, but it's just the way it is. --Cliff Thanks Cliff!! I'll grab the latest apr and apr-util and give that a shot. I knew there was an explanation. Cheers, -- Trev -- Trevor Hurst Senior Systems Administrator DCO Unix Production Systems Silicon Graphics Office Ph: 650.933.6144 e-mail: [EMAIL PROTECTED] pager: [EMAIL PROTECTED] -- Thus a mind that is free from passion is a very citadel; man has no stronger fortress in which to seek shelter and defy every assault. Failure to perceive this is ignorance; but to perceive it, and still not to seek its refuge, is misfortune indeed. --Marcus Aurelius
Re: PR 17462: let mod_rewrite hard limit its internal redirects
André Malo wrote: * Mads Toftum wrote: Generally I like the idea, but I'm a bit wary about setting a default value other than unlimited because it could break existing configs. hmm, the idea behind is actually to break the configs (anyway) to prevent the server from crashing. 10 internal redirects are already a lot ones. But however, we could let it default to, 20, 50 or 100. I don't believe that such a high value would break any config (it's probably already broken then ...). YMMV. Some more opinions about that point are welcome. It's hard for me to imagine a case where 10 mod_rewrite internal redirects for the same request are legitimate. I think 10 is a fine default value. Greg
Re: minor MMN bump for 2.0
William A. Rowe, Jr. wrote: At 05:07 PM 2/26/2003, Greg Ames wrote: Sure. A handler which does its own apr_file_open looses the ability to use sendfile. Who cares? Only people who value performance. That's an APR implementation-dependent detail that you (the module/app author) has minimal control over. APR has nothing to do with how it works on Unix, other than being used as a parameter passing mechanism between the default_handler and the core_input_filter. Sure, APR comes into play on Win95, but I don't think there are a whole lot of people seriously trying to maximize Apache performance on Win95. Greg
Re: PR 17462: let mod_rewrite hard limit its internal redirects
On Thu, Feb 27, 2003 at 06:17:57PM +0100, André Malo wrote: hmm, the idea behind is actually to break the configs (anyway) to prevent the server from crashing. 10 internal redirects are already a lot ones. But however, we could let it default to, 20, 50 or 100. I don't believe that such a high value would break any config (it's probably already broken then ...). YMMV. Some more opinions about that point are welcome. On second thought (after looking through my odd collection of rewrite examples) I do tend to agree with you, since I'm having a very hard time imagining any case where even more than a couple would be useful. So I'm all for limiting to 10 (or even 5 for that matter) as long as it will result in an explanatory message to the error_log (LogLevel debug). vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
PR 15282 AcceptEx problem
As far as I can tell this is a bug in the Sprint
PCS Connect support for AcceptEx, (they install a
Winsock transport provider called BMI). However, it slips
through our checks and causes the accept thread to
hard loop and consume most of the cpu.
What happens is that in get_listeners_from_parent()
WSASocket *succeeeds* using the WSAProtocolInfo from
the parent however, AcceptEx in winnt_accept() fails
with WSAENOTSOCK.
I don't see what we can do to fix this but we should
at least avoid hogging the cpu and log an informative
message. Unless there is a better idea I'll commit to 2.1
16327 may be related but I haven't been able to recreate
the problem with BlackIce or Norton Personal Firewall.
Allan
Index: child.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/child.c,v
retrieving revision 1.12
diff -u -d -b -r1.12 child.c
--- child.c 26 Feb 2003 21:55:54 - 1.12
+++ child.c 27 Feb 2003 16:38:59 -
@@ -498,7 +498,7 @@
PCOMP_CONTEXT context = NULL;
DWORD BytesRead;
SOCKET nlsd;
-int rv;
+int rv, err_count = 0;
apr_os_sock_get(nlsd, lr-sd);
@@ -547,6 +547,14 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, ap_server_conf,
winnt_accept: AcceptEx failed due to early client
disconnect. Reallocate the accept socket and try again.);
+
+Sleep(100);
+if (++err_count 100) {
+ap_log_error(APLOG_MARK,APLOG_ERR, rv, ap_server_conf,
+ AcceptEx unrecoverable error,
+ possibly incompatible firewall or VPN software is
installed.);
+break;
+}
continue;
}
else if ((rv != APR_FROM_OS_ERROR(ERROR_IO_PENDING))
@@ -558,6 +566,7 @@
Sleep(100);
continue;
}
+err_count = 0;
/* Wait for pending i/o.
* Wake up once per second to check for shutdown .
Index: child.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/child.c,v
retrieving revision 1.12
diff -u -d -b -r1.12 child.c
--- child.c 26 Feb 2003 21:55:54 - 1.12
+++ child.c 27 Feb 2003 16:38:59 -
@@ -498,7 +498,7 @@
PCOMP_CONTEXT context = NULL;
DWORD BytesRead;
SOCKET nlsd;
-int rv;
+int rv, err_count = 0;
apr_os_sock_get(nlsd, lr-sd);
@@ -547,6 +547,14 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, ap_server_conf,
winnt_accept: AcceptEx failed due to early client
disconnect. Reallocate the accept socket and try again.);
+
+Sleep(100);
+if (++err_count 100) {
+ap_log_error(APLOG_MARK,APLOG_ERR, rv, ap_server_conf,
+ AcceptEx unrecoverable error,
+ possibly incompatible firewall or VPN software is
installed.);
+break;
+}
continue;
}
else if ((rv != APR_FROM_OS_ERROR(ERROR_IO_PENDING))
@@ -558,6 +566,7 @@
Sleep(100);
continue;
}
+err_count = 0;
/* Wait for pending i/o.
* Wake up once per second to check for shutdown .
Re: PR 15282 AcceptEx problem
Humm... how do our friends at MS solve this in IIS?
Bill
Allan Edwards wrote:
As far as I can tell this is a bug in the Sprint
PCS Connect support for AcceptEx, (they install a
Winsock transport provider called BMI). However, it slips
through our checks and causes the accept thread to
hard loop and consume most of the cpu.
What happens is that in get_listeners_from_parent()
WSASocket *succeeeds* using the WSAProtocolInfo from
the parent however, AcceptEx in winnt_accept() fails
with WSAENOTSOCK.
I don't see what we can do to fix this but we should
at least avoid hogging the cpu and log an informative
message. Unless there is a better idea I'll commit to 2.1
16327 may be related but I haven't been able to recreate
the problem with BlackIce or Norton Personal Firewall.
Allan
Index: child.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/child.c,v
retrieving revision 1.12
diff -u -d -b -r1.12 child.c
--- child.c26 Feb 2003 21:55:54 -1.12
+++ child.c27 Feb 2003 16:38:59 -
@@ -498,7 +498,7 @@
PCOMP_CONTEXT context = NULL;
DWORD BytesRead;
SOCKET nlsd;
-int rv;
+int rv, err_count = 0;
apr_os_sock_get(nlsd, lr-sd);
@@ -547,6 +547,14 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, ap_server_conf,
winnt_accept: AcceptEx failed due to early
client
disconnect. Reallocate the accept socket and
try again.);
+
+Sleep(100);
+if (++err_count 100) {
+ap_log_error(APLOG_MARK,APLOG_ERR, rv, ap_server_conf,
+ AcceptEx unrecoverable error,
+ possibly incompatible firewall or VPN
software is installed.);
+break;
+}
continue;
}
else if ((rv != APR_FROM_OS_ERROR(ERROR_IO_PENDING))
@@ -558,6 +566,7 @@
Sleep(100);
continue;
}
+err_count = 0;
/* Wait for pending i/o.
* Wake up once per second to check for shutdown .
Index: child.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/child.c,v
retrieving revision 1.12
diff -u -d -b -r1.12 child.c
--- child.c 26 Feb 2003 21:55:54 - 1.12
+++ child.c 27 Feb 2003 16:38:59 -
@@ -498,7 +498,7 @@
PCOMP_CONTEXT context = NULL;
DWORD BytesRead;
SOCKET nlsd;
-int rv;
+int rv, err_count = 0;
apr_os_sock_get(nlsd, lr-sd);
@@ -547,6 +547,14 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, ap_server_conf,
winnt_accept: AcceptEx failed due to early client
disconnect. Reallocate the accept socket and try again.);
+
+Sleep(100);
+if (++err_count 100) {
+ap_log_error(APLOG_MARK,APLOG_ERR, rv, ap_server_conf,
+ AcceptEx unrecoverable error,
+ possibly incompatible firewall or VPN software is installed.);
+break;
+}
continue;
}
else if ((rv != APR_FROM_OS_ERROR(ERROR_IO_PENDING))
@@ -558,6 +566,7 @@
Sleep(100);
continue;
}
+err_count = 0;
/* Wait for pending i/o.
* Wake up once per second to check for shutdown .
Re: PR 15282 AcceptEx problem
Bill Stoddard wrote: Humm... how do our friends at MS solve this in IIS? It only happens because of our parent-child process model. If you run -X the problem goes away. It's the socket duplication that seems to bite us. Allan
Re: [PATCH] small optimization in ap_meets_conditions() andquestions
Since the target value is in second, it should be possible to use
r-request_time instead of calling apr_time_now().
I ran a load test on my box and did not ever see a difference between the
sec value in r-request_time and the one returned by apr_time_now().
end of the patchpart..
---
Questions:
1-
It should also be valuable to change the return format of
apr_date_parse_http() to be in seconds instead of uSEC.
This is a snippet of the last part of that function:
--- boc ---
/* ap_mplode_time uses tm_usec and tm_gmtoff fields, but
they haven't * been set yet.
* It should be safe to just zero out these
values. * tm_usec is the number of microseconds into
the second. HTTP only * cares about second
granularity. * tm_gmtoff is the number of seconds
off of GMT the time is. By * definition all
times going through this function are in GMT, so
this * is zero.
*/ ds.tm_usec = 0;--- eoc ---
and the time is exploded to match the apr_time_t format.
A call to apr_date_parse_httpd() is usually followed by a call to
apr_time_sec(), which do a 64 bits division to get the time in second.
What about having a new function called apr_date_parse_httpd_sec(), which
skip the end part of apr_time_exp_get() and return seconds?
It implies a small change to apr_time_exp_get() and moving the core code in
apr_time_exp_get() to apr_time_exp_get_sec().:
--- boc ---
APR_DECLARE(apr_status_t) apr_time_exp_get(apr_time_t *t, apr_time_exp_t
*xt){ apr_status_t ret;
ret = apr_time_exp_get_sec(t, xt);
if (ret == APR_SUCCESS)
*t = *t * APR_USEC_PER_SEC +
xt-tm_usec;
return ret;}--- eoc ---
---
2:
What about creating a new define called:
#define APR_HAS_USEC.
The else of that optioncould allow apache to run using ONLY sec for
all apr_time_t field removing all 64 bits division to transform uSEC to
sec.
The size of the apr_time_t variables could also be changed to 32 bits and
calls to gettimeofday() changed to time().
Why is apache using uSEC, when time variables are mostly used in seconds at
run-time, and that http requirements use seconds from my modest knownledge.
The performance gain is minor but measurable: between 1 and 2.5%on my
box (from 1 to 4 CPUs).
---
3:
On having atime variable in the mpm keeping updated sec and uSEC
field:
NetWare has its main thread resuming every 100 uSEC (1 sec) to do the
idle server maintenance.
I am thinkingof using a set of functions like the following
ones:
--- boc ---
static apr_int32_t mpm_clock_initialized;static apr_time_t
now;struct timeval tv;
static void synchonize_usec_clock( void ){ static apr_int32_t
counter; if (mpm_clock_initialized) {
if(++counter 4) { gettimeofday(tv,
NULL); now = tv.tv_sec * APR_USEC_PER_SEC +
tv.tv_usec; counter = 0;
} else now +=
SCOREBOARD_MAINTENANCE_INTERVAL; } else
{ gettimeofday(tv, NULL); now =
tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
mpm_clock_initialized = 1; }}
AP_DECLARE(apr_time_t) ap_time_now(void){if
(mpm_clock_initialized) return now;
else return apr_time_now();}--- eoc ---
The synchonize_usec_clock() function is called every second by the main
thread.
Itsynchronizes the time fields every 5 seconds using the
gettimeofday() function.
Calls to apr_time_now() in apache could then be replaced with call to
ap_time_now().
---
Thank you,
Jean-Jacques
Re: PR 15282 AcceptEx problem
Allan Edwards wrote: Bill Stoddard wrote: Humm... how do our friends at MS solve this in IIS? It only happens because of our parent-child process model. If you run -X the problem goes away. It's the socket duplication that seems to bite us. Allan Perhaps we need a winnt mpm directive to force the server to use the Win9* accept code path. Whould be a terrible thing to do on a production level server (for performance reasons) but quite okay for most of the folks that are seeing personal firewalls collide with our use of AcceptEx. Bill
Re: PR 15282 AcceptEx problem
Perhaps we need a winnt mpm directive to force the server to use the Win9* accept code path. Whould be a terrible thing to do on a production level server (for performance reasons) but quite okay for most of the folks that are seeing personal firewalls collide with our use of AcceptEx. mmm... that might work. PCS Connect has no problem with the accept() call. Allan
Re: [PATCH] openssl configuration
Hi Madhu, * MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) ([EMAIL PROTECTED]) wrote: I haven't gone through the entire stuff, but some quick questions, based on your patch : Thanks for the initial feedback, it's certainly useful to know this code has been on other people's minds, and that I didn't just stumble onto something old and forgotten. 1. I thought we should not be enforcing openssl version number checks (something like - openssl version SHOULD be 0.9.6i) - mainly because ppl. can apply patches to their previous versions of OpenSSL, and thus avoid security problems.. (ofcourse, I know you're coming from the OpenSSL background, but that was the message I got here when I tried doing something like that) I put the version checks in simply because there are version checks in the existing M4 stuff and I would have thought it unacceptable to the ASF for me to remove them! :-) The current version checks are implemented in a cock-eyed fashion and are also out of date (0.9.6e used to be a meaningful cut-off point, but that has changed more recently). It would perhaps make sense to provide a --force-ssl-ver type of option that would bypass version checks, and then have any version checking failure text point out the existence of --force-ssl-ver. This way, the more determined users can force configure to bypass that, whilst it still provides a certain safety-net for the more naive and less intrepid against accidently meddling with known-to-be-out-of-date support libraries. 2. Regarding hardcoding openssl/some_header_name.h, I think it's a bad idea - how about ppl. who want to use other SSL toolkits along with apache ?. Erm, like what? The only candidate I can think of would be the RSA-C toolkit? If so, I would say that it doesn't make much sense to try and deliberately reduce the focus (or increase the blur, if you prefer) of the configuration checking so that something other than openssl still slips through the configuration looking like openssl. The complexity doesn't seem worth the trouble to me. To support other SSL toolkits, the more sensible approach would be to introduce alternative autoconf checks that are tailored to those toolkits. But anyway, I find it difficult to imagine that the existing version checks in Apache's configure was letting through alternative toolkits anyway?? So perhaps something like --with-rsa-c could be implemented, and it would be able to target RSA-C directly without needing to be fudged to only check things common to both RSA-C and OpenSSL. Likewise, the includes in mod_ssl.h should be #ifdef,#elif,#endif'd so that you get precisely the headers you need for precisely the toolkit you are using (and using precisely the header paths defined in the respective API). The more things go, the more OpenSSL and RSA-C are likely to diverge - I strongly suspect they've already diverged too far for the code in its current form, but perhaps I'm mistaken there. If the only issue right now between the two is what prefix we do or don't add to the include paths, then that should be considered extremely good fortune. Sooner or later though, we'd end up needing to separating things with precompiler logic to handle differences between toolkits, syntax, symbol definitions, enhancements, optional extras, etc. Failing to do that in the autoconf support or the SSL/TLS module code puts Apache in a position of being dependant on two entirely independant development projects remaining similar enough. That's not a solid position to maintain, and you lose any ability to tune to (or benefit from) a toolkit's evolution. It also goes against the grain of why things like autoconf exist. Of course, I'm hardly about to donate hours or days of my own time to further RSA's commercial cause. :-) But if doing some re-organisation work will benefit apache and openssl as well, I wouldn't begrudge helping create targetted support mechanisms for both OpenSSL and RSA-C. It certainly seems a better way to go than taking a hands-off approach to the use of fork()d toolkits - nobody can give Apache or its users any guarantees that they'll be able to rely on continued similarities. Or were you referring to SSLeay? Or compability layers built on top of something else? Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
Re: cvs commit: httpd-2.0/server connection.c
Jeff Trawick wrote: William A. Rowe, Jr. wrote: They should, ap_run_pre_connection is an Apache hook. Yes, it returns an int, so the only change here should be -apr_status_t rc; +int rc; We aren't calling apr_ function here, and hooks always allow OK, DONE, or (result). ahh, that's the missing piece of commentary on Stas' commit to explain various confusion :) So, everybody agrees that it should be: -apr_status_t rc; +int rc; correct? __ 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] openssl configuration
-Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] [SNIP] The current version checks are implemented in a cock-eyed fashion and are also out of date (0.9.6e used to be a meaningful cut-off point, but that has changed more recently). I agree that the current check is out-of-place, and it has to be changed. But, your proposal of error'ing out based on version number is what concerned me. Think of ppl. who've patched their sources with the fixes ?. You don't want to be rejecting the toolkit based on the version number available in the header file. I got a lot of push-back (locally also) for proposing something like that. But, having said that, I don't know of a better method of informing the users. It would perhaps make sense to provide a --force-ssl-ver type of option that would bypass version checks, and then have any version checking failure text point out the existence of --force-ssl-ver. [SNIP] I like that.. If ppl. don't care what version of openssl they use, force them to move to the latest.. For others, they can always use the --force-ssl-ver flag. Does anybody else have comments ?. [SNIP] Erm, like what? The only candidate I can think of would be the RSA-C toolkit? ... The complexity doesn't seem worth the trouble to me. Well, I actually went through the whole process of trying to get apache + mod_ssl working with RSA toolkit :) [I just haven't been able to put it to-gether and submit a patch]. Although I realize that lots of ppl. are moving towards OpenSSL, I believe there are ppl out there who'd like to have a alternative to the OpenSSL kit. Think about having better SSL performance, the RSA toolkit performs better than OpenSSL toolkit [no bad feelings].. By introducing openssl specific stuff, we'd be making it more difficult to use mod_ssl (+ Apache) with any other kits. BUT, if ppl on the httpd-community think different, I have no problems to make mod_ssl be more OpenSSL friendly.. To support other SSL toolkits, the more sensible approach would be to introduce alternative autoconf checks that are tailored to those toolkits. [SNIP] I find it easier to use the same options for both OpenSSL and RSA.. The autoconf can verify the existance of RSA specific header files, and realize that it's a RSA toolkit and not OpenSSL. But again, this is my personal opinion here.. I don't know what's the best option - any suggestions ?. Likewise, the includes in mod_ssl.h should be #ifdef,#elif,#endif'd so that you get precisely the headers you need for precisely the toolkit you are using (and using precisely the header paths defined in the respective API). It's being done in the sources today (in ssl_toolkit_compat.h) The more things go, the more OpenSSL and RSA-C are likely to diverge - I strongly suspect they've already diverged too far for the code in its current form, but perhaps I'm mistaken there. If the only issue right now between the two is what prefix we do or don't add to the include paths, then that should be considered extremely good fortune. Sooner or later though, we'd end up needing to separating things with precompiler logic to handle differences between toolkits, syntax, symbol definitions, enhancements, optional extras, etc. I don't know how many others have tried to do this, but based on my experience, most of the changes went into a header file.. There were very little modifications required to the .c files. However, I do echo your concern regarding how long will it be, before the two go in different ways. It might become more difficult to maintain one code base for supporting both the toolkits. -Madhu
[STATUS] (apache-1.3) Thu Feb 27 19:20:47 EST 2003
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2003/02/04 19:08:59 $] Release: 1.3.28-dev: In development 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Current vote on 2 PRs for inclusion: Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: [EMAIL PROTECTED] Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore file-extension should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) * Salvador Ortiz Garcia [EMAIL PROTECTED]' patch to allow DirectoryIndex to refer to URIs for non-static resources. MID: [EMAIL PROTECTED] Status: Ken +1 (on concept), Lars +1 (on concept) * Brian
[STATUS] (httpd-2.0) Thu Feb 27 19:20:57 EST 2003
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2003/02/24 00:00:05 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.0 : in development Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * just do an egrep on TODO or XXX and see what's there CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter) d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * RFC 2616 violations. Closed PRs: 15857. Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869, 15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137, 16138, 16139, 16140, 16142, 16518, 16520, 16521, jerenkrantz says: need to decide how many we need to backport and/or if these rise to showstopper status. * There is a bug in how we sort some hooks, at least the pre-config hook. The first time we call the hooks, they are in the correct order, but the second time, we don't sort them correctly. Currently, the modules/http/config.m4 file has been renamed to modules/http/config2.m4 to work around this problem, it should moved back when this is fixed. OtherBill offers that this is a SERIOUS problem. We do not sort correctly by the ordering arguments passed to the register hook functions. This was proven when I reordered the open_logs hook to attempt to open the error logs prior to the access logs. Possibly the entire sorting code needs to be refactored. * pipes deadlock on all platforms with limited pipe buffers (e.g. both Linux and Win32, as opposed to only Win32 on 1.3). The right solution is either GStein's proposal for a CGI Brigade, or OtherBill's proposal for Poll Buckets for Polling Filter Chains. Or maybe both :-) * All handlers should always send content down even if r-header_only is set. If not, it means that the HEAD requests don't generate the same headers as a GET which is wrong. * HP/UX 10.20: compile breakage in APR. Looks like it should be easy to fix, probably just some extraneous #include's that are fouling things up. PR: 9457 Jeff: See my reply and patch in the PR (and previous commit to stop using pipe as a field name). If patch is committed, we should be okay. I'll wait to see if the user tests the patch. Update by Jeff 20020722: I got an account on HP 10.20. It looks like some of the APR thread detection is screwed up. If we find pthread.h but we can't
Re: Apache 2.0.44 w/ auth_ldap build errors
Cliff Woolley wrote: On Wed, 26 Feb 2003, Trevor Hurst wrote: Because when I run the make I get the following errors: -static -c mod_auth_ldap.c touch mod_auth_ldap.lo mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to have LDAP support built in If you go into the apr-util directory and run ./configure --help, among other things it will tell you: --with-ldap-include=path path to ldap include files with trailing slash --with-ldap-lib=pathpath to ldap lib file --with-ldap=library ldap library to use Go back to the top-level Apache directory and pass ./configure these arguments, and it will pass them through to apr-util for you. I admit this is not entirely obvious, but it's just the way it is. --Cliff Man this is frustrating. I went ahead and installed LDAP and point the proper parameters as you suggested to the locations where ldap is installed and it complains of not finding ldap.. Here's the output from:--with-ldap-lib=/usr/freeware/lib32/libldap.so.3 ./configure --with-ldap-include=/usr/freeware/include/ --with-ldap-lib=/usr/freeware/lib32/ --with-ldap=libldap.so.3 --enable-auth-ldap and get the following: APR-util Version: 0.9.2 checking for chosen layout... apr-util Applying apr-util hints file rules for mips-sgi-irix6.5 checking for APR... yes checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking for ldap support... setting APRUTIL_INCLUDES to -I/usr/freeware/include/ setting APRUTIL_LDFLAGS to -L/usr/freeware/lib32/libldap.so.3 checking for ldap_init in -lldap50... no checking for ldap_init in -lldapssl41... no checking for ldap_init in -lldapssl40... no checking for ldap_init in -lldapssl30... no checking for ldap_init in -lldapssl20... no checking for ldap_init in -lldap... no checking for ldap_init in -lldap... (cached) no checking for ldap_init in -lldap... (cached) no configure: error: could not find an LDAP library configure failed for srclib/apr-util Any ideas now? I am running out of ideas ;-/ Thanks, -- Trev -- Trevor Hurst Senior Systems Administrator DCO Unix Production Systems Silicon Graphics Office Ph: 650.933.6144 e-mail: [EMAIL PROTECTED] pager: [EMAIL PROTECTED] -- Thus a mind that is free from passion is a very citadel; man has no stronger fortress in which to seek shelter and defy every assault. Failure to perceive this is ignorance; but to perceive it, and still not to seek its refuge, is misfortune indeed. --Marcus Aurelius
Re: Apache 2.0.44 w/ auth_ldap build errors
Trevor Hurst wrote: setting APRUTIL_INCLUDES to -I/usr/freeware/include/ setting APRUTIL_LDFLAGS to -L/usr/freeware/lib32/libldap.so.3 the argument of -L should be a directory, not a file
Re: Apache 2.0.44 w/ auth_ldap build errors
Jeff Trawick wrote: Trevor Hurst wrote: setting APRUTIL_INCLUDES to -I/usr/freeware/include/ setting APRUTIL_LDFLAGS to -L/usr/freeware/lib32/libldap.so.3 the argument of -L should be a directory, not a file Acutally, sorry, my mistake, that was the output of another configure I was doing after I changed some of the params around. I still get this when doing it the way Cliff suggested: checking for ldap support... setting APRUTIL_INCLUDES to -I/usr/freeware/include/ setting APRUTIL_LDFLAGS to -L/usr/freeware/lib32/ checking for ldap_init in -l... no configure: error: could not find an LDAP library configure failed for srclib/apr-util argh! ;-/ -- Trevor Hurst Senior Systems Administrator DCO Unix Production Systems Silicon Graphics Office Ph: 650.933.6144 e-mail: [EMAIL PROTECTED] pager: [EMAIL PROTECTED] -- Thus a mind that is free from passion is a very citadel; man has no stronger fortress in which to seek shelter and defy every assault. Failure to perceive this is ignorance; but to perceive it, and still not to seek its refuge, is misfortune indeed. --Marcus Aurelius
Re: Apache 2.0.44 w/ auth_ldap build errors
On Thu, 27 Feb 2003, Jeff Trawick wrote: it would be useful if ./configure --help for Apache would also display apr and apr-util --help screen if the Apache configure is going to configure apr and apr-util as well ++1!
Re: [PATCH] Move http header parsing into the http_input_filter
I am working on the next rev of this patch fixing some of the problems pointed out by Justin and Bill R. I have the most concern about protocol negotiation. What's in store for HTTP post 1.1? We may have much bigger problems than simply replacing a filter. Bill
Re: PR 17462: let mod_rewrite hard limit its internal redirects
* Mads Toftum wrote:
On second thought (after looking through my odd collection of rewrite examples)
I do tend to agree with you, since I'm having a very hard time imagining
any case where even more than a couple would be useful. So I'm all for
limiting to 10 (or even 5 for that matter) as long as it will result in an
explanatory message to the error_log (LogLevel debug).
Well, attached a patch to limit the redirects. I'm just unsure before
committing: One can use
RewriteOptions MaxRedirects=n
to change the limit (also during a redirect, seems to make sense for me
anyway). In contrast to all the other mod_rewrite config stuff it's
inherited all the time regardless of the RewriteOptions inherit setting. Is
that behaviour okay or should we respect the inherit option here, too?
Just FYI: my little testsuite. Put the following into the document root
directory container ... (after applying the patch ;-)
RewriteEngine On
#RewriteOptions MaxRedirects=20
RewriteBase /
RewriteRule (.*) / [L]
TIA, nd
--
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, http://pub.perlig.de/ #
diff -Nur httpd-2.1/modules/mappers/mod_rewrite.c
httpd-2.1.rewriteloop/modules/mappers/mod_rewrite.c
--- httpd-2.1/modules/mappers/mod_rewrite.c Thu Feb 27 04:08:06 2003
+++ httpd-2.1.rewriteloop/modules/mappers/mod_rewrite.c Fri Feb 28 01:56:46 2003
@@ -206,6 +206,7 @@
a-rewriteconds= apr_array_make(p, 2, sizeof(rewritecond_entry));
a-rewriterules= apr_array_make(p, 2, sizeof(rewriterule_entry));
a-server = s;
+a-redirect_limit = 0; /* unset (use default) */
return (void *)a;
}
@@ -222,6 +223,9 @@
a-state = overrides-state;
a-options = overrides-options;
a-server = overrides-server;
+a-redirect_limit = overrides-redirect_limit
+ ? overrides-redirect_limit
+ : base-redirect_limit;
if (a-options OPTION_INHERIT) {
/*
@@ -278,6 +282,7 @@
a-baseurl = NULL;
a-rewriteconds= apr_array_make(p, 2, sizeof(rewritecond_entry));
a-rewriterules= apr_array_make(p, 2, sizeof(rewriterule_entry));
+a-redirect_limit = 0; /* unset (use server config) */
if (path == NULL) {
a-directory = NULL;
@@ -308,6 +313,9 @@
a-options = overrides-options;
a-directory = overrides-directory;
a-baseurl = overrides-baseurl;
+a-redirect_limit = overrides-redirect_limit
+ ? overrides-redirect_limit
+ : base-redirect_limit;
if (a-options OPTION_INHERIT) {
a-rewriteconds = apr_array_append(p, overrides-rewriteconds,
@@ -351,34 +359,48 @@
static const char *cmd_rewriteoptions(cmd_parms *cmd,
void *in_dconf, const char *option)
{
-rewrite_perdir_conf *dconf = in_dconf;
-rewrite_server_conf *sconf;
-const char *err;
+int options = 0, limit = 0;
+char *w;
-sconf = ap_get_module_config(cmd-server-module_config, rewrite_module);
+while (*option) {
+w = ap_getword_conf(cmd-pool, option);
-if (cmd-path == NULL) { /* is server command */
-err = cmd_rewriteoptions_setoption(cmd-pool,
- (sconf-options), option);
-}
-else { /* is per-directory command */
-err = cmd_rewriteoptions_setoption(cmd-pool,
- (dconf-options), option);
+if (!strcasecmp(w, inherit)) {
+options |= OPTION_INHERIT;
+}
+else if (!strncasecmp(w, MaxRedirects=, 13)) {
+limit = atoi(w[13]);
+if (limit = 0) {
+return RewriteOptions: MaxRedirects takes a number greater
+ than zero.;
+}
+}
+else if (!strcasecmp(w, MaxRedirects)) { /* be nice */
+return RewriteOptions: MaxRedirects has the format MaxRedirects
+ =n.;
+}
+else {
+return apr_pstrcat(cmd-pool, RewriteOptions: unknown option ',
+ w, ', NULL);
+}
}
-return err;
-}
+/* put it into the appropriate config */
+if (cmd-path == NULL) { /* is server command */
+rewrite_server_conf *conf =
+ap_get_module_config(cmd-server-module_config,
+ rewrite_module);
-static const char *cmd_rewriteoptions_setoption(apr_pool_t *p, int *options,
-const char *name)
-{
-if (strcasecmp(name, inherit) == 0) {
-*options |= OPTION_INHERIT;
+conf-options |= options;
+conf-redirect_limit = limit;
}
-else {
-return apr_pstrcat(p, RewriteOptions: unknown option ',
- name, ', NULL);
+else { /* is per-directory command */
+rewrite_perdir_conf *conf = in_dconf;
+
mod_authn_dbi... first release...
It is heavily based off of mod_authn_mysql. It uses libdbi( http://libdbi.sf.net ) as an abstraction layer. I personaly have only had a chance to use MySQL as a backend, it should work easily with PgSQL if libdbi does its job. You can get it now on: http://open.cyanworlds.com/ I even bothered to add some CSS to the website so that is isn't as bland :-) comments, questions, and flames are all welcome, some more than others. -chip
