Per-module loglevel configuration
Hi, here is the second version of my patch to allow per-module loglevel configuration. It's available at: http://people.apache.org/~sf/per-module-loglevel-v2/ As it's rather big, I have split it into separate logical patches. I hope this makes it easier to review: 0001 Add macro wrappers for ap_log_*error 0002 Introduce log levels trace1/.../trace8 0003 Introduce SSLLOG_MARK, in preparation to redefine APLOG_MARK 0004 move find module logic into separate function 0005 Introduce per module log levels 0006 Adjust mod_ssl logging to make it compile again 0007 define APLOG_MODULE_INDEX in module files 0008 define APLOG_MODULE_INDEX in core files and remove default definition of APLOG_MODULE_INDEX 0009 Replace LogLevelDebugDump with TRACE log levels 0010 Replace DumpIOLogLevel with trace log level 0011 Replace RewriteLog/RewriteLogLevel with trace log levels As I wrote in the mail to Graham, I didn't have time to work on the per-directory loglevel configuration. But even without it, this patch is quite an improvement, IMHO. Cheers, Stefan
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On Mar 16, 2010, at 12:24 PM, Noirin Shirley wrote: > On Tue, Mar 16, 2010 at 8:05 PM, William A. Rowe Jr. > wrote: >> On 3/16/2010 12:37 PM, Noirin Shirley wrote: >>> >>> In some places, we use httpd, but that leads to some horrible >>> confusion between the product and the command. >> >> I guess I'm not seeing the disconnect. If a reader cannot parse httpd >> as shorthand "the Apache HTTP Server program", then we have more serious >> issues in helping them become a web server administrator. > > The problem is that httpd is used as shorthand for "the Apache HTTP > Server" *and* as a reference to a specific binary/process/command, and > we assume that people can work out the difference, because, y'know, > Bill knows the difference, and Roy does, so obviously, all the rest of > us should too. No, they can work out the difference (assuming they ever need to) by looking at the context. > If the command were, say, "apache2", then just using "Apache HTTP > Server (httpd)" for the first mention, and "httpd" thereafter would be > fine. Heck, even if we absolutely always used "apachectl", and never > referred to the binary directly, we might be able to get something > that worked, although there'd be a lot more rewriting of docs > required. But when it's not always clear to people who've been working > on the project for years whether a given instance of "httpd" refers to > a single binary or a set of binaries, and config files, and sometimes > other bits and pieces, how on earth do we expect users to be able to > grok what we're talking about? > > And as for clueless lawyers, unless we've given one commit access, > they're not the only ones using HTTPd either - cf > http://httpd.apache.org/docs/2.2/install.html Yes, both Joshua Slive and Ken Coar would (very rarely) capitalize the HTTP for no apparent reason, as would various denizens of other projects (NCSA HTTPd post-1.5, kHTTPd, OmniHTTPd, etc.). That doesn't make it our product name. A patch to make everything consistently wrong is not an improvement over being inconsistently wrong in our docs. Roy
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On 03/16/2010 09:37 PM, William A. Rowe Jr. wrote: I thought the only people who ever capitalize HTTP in httpd are clueless lawyers. apache_1.2.4.tar.gz/ABOUT_APACHE The Apache HTTP Server Project http://www.apache.org/ June 1997 Seems the HTTPD is used for a long time I'm sorry, I'm looking at your snip and I don't see a captial D. Choose one. D or d :) IMHO Apache HTTPD is no better then Apache httpd. It should be Apache Httpd thought. Regards -- ^TM
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On 3/16/2010 2:58 PM, Mladen Turk wrote: > On 03/16/2010 06:24 PM, Roy T. Fielding wrote: >> >> I thought the only people who ever capitalize HTTP in httpd are >> clueless lawyers. > > apache_1.2.4.tar.gz/ABOUT_APACHE > > The Apache HTTP Server Project > http://www.apache.org/ > June 1997 > > Seems the HTTPD is used for a long time I'm sorry, I'm looking at your snip and I don't see a captial D.
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On 03/16/2010 06:24 PM, Roy T. Fielding wrote: I thought the only people who ever capitalize HTTP in httpd are clueless lawyers. apache_1.2.4.tar.gz/ABOUT_APACHE The Apache HTTP Server Project http://www.apache.org/ June 1997 Seems the HTTPD is used for a long time Regards -- ^TM
Re: svn commit: r923429 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
On Tue, 16 Mar 2010, Ruediger Pluem wrote:
On 15.03.2010 21:46, s...@apache.org wrote:
Author: sf
Date: Mon Mar 15 20:46:26 2010
New Revision: 923429
URL: http://svn.apache.org/viewvc?rev=923429&view=rev
Log:
get the socket with ap_get_module_config instead of walking the filter chain
Modified:
httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Modified: httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_reqtimeout.c?rev=923429&r1=923428&r2=923429&view=diff
==
--- httpd/httpd/trunk/modules/filters/mod_reqtimeout.c (original)
+++ httpd/httpd/trunk/modules/filters/mod_reqtimeout.c Mon Mar 15 20:46:26 2010
@@ -151,21 +151,7 @@ static apr_status_t reqtimeout_filter(ap
}
if (!ccfg->socket) {
-core_net_rec *net_rec;
-ap_filter_t *core_in = f->next;
-
-while (core_in && core_in->frec != ap_core_input_filter_handle)
-core_in = core_in->next;
-
-if (!core_in) {
-ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, f->c,
- "mod_reqtimeout: Can't get socket "
- "handle from core_input_filter");
-ap_remove_input_filter(f);
-return ap_get_brigade(f->next, bb, mode, block, readbytes);
-}
-net_rec = core_in->ctx;
-ccfg->socket = net_rec->client_socket;
+ccfg->socket = ap_get_module_config(f->c->conn_config, &core_module);
Not quite sure if this data structure is part of the API. If not the core could
change it anytime and the above assignment could fail then.
Other modules do the same, so mod_reqtimeout does not create an additional
problem IMHO:
$ grep -rl ap_get_module_config.*conn_config.*core_module modules
modules/proxy/mod_proxy_connect.c
modules/proxy/mod_proxy_fdpass.c
modules/filters/mod_reqtimeout.c
modules/http/http_core.c
modules/echo/mod_echo.c
modules/experimental/mod_noloris.c
Re: ProxyPreserveHost per dir??
On Tuesday 16 March 2010, Akins, Brian wrote: > Is there a particular reason why ProxyPreserveHost is per server > and not per dir? We have some "unusual" configs and I'm wondering > what secret internals I may be breaking by changing that? The > code didn't show anything obvious. It's per dir since 2.3.3. The change breaks module binary compatibility and therefore cannot be backported to 2.2.x.
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On Tue, Mar 16, 2010 at 8:30 PM, William A. Rowe Jr. wrote: > On 3/16/2010 2:24 PM, Noirin Shirley wrote: >> On Tue, Mar 16, 2010 at 8:05 PM, William A. Rowe Jr. >> wrote: >>> On 3/16/2010 12:37 PM, Noirin Shirley wrote: In some places, we use httpd, but that leads to some horrible confusion between the product and the command. >>> >>> I guess I'm not seeing the disconnect. If a reader cannot parse httpd >>> as shorthand "the Apache HTTP Server program", then we have more serious >>> issues in helping them become a web server administrator. >> >> The problem is that httpd is used as shorthand for "the Apache HTTP >> Server" *and* as a reference to a specific binary/process/command, and >> we assume that people can work out the difference, because, y'know, >> Bill knows the difference, and Roy does, so obviously, all the rest of >> us should too. > > Actually; > > the command is usually apachectl ;-) Unfortunately "usually" isn't the same as "always", and that only adds to the confusion. I know that you know what you're talking about when you say httpd, in any context. But a user coming to our docs sees the same word used as a process name, and as a product name, and then as a command, and then they're told they shouldn't use that command, ... Not everyone can be VP of the project. The docs are meant to make it easier for the people who *aren't* VP to use our software. Noirin
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On 3/16/2010 2:24 PM, Noirin Shirley wrote: > On Tue, Mar 16, 2010 at 8:05 PM, William A. Rowe Jr. > wrote: >> On 3/16/2010 12:37 PM, Noirin Shirley wrote: >>> >>> In some places, we use httpd, but that leads to some horrible >>> confusion between the product and the command. >> >> I guess I'm not seeing the disconnect. If a reader cannot parse httpd >> as shorthand "the Apache HTTP Server program", then we have more serious >> issues in helping them become a web server administrator. > > The problem is that httpd is used as shorthand for "the Apache HTTP > Server" *and* as a reference to a specific binary/process/command, and > we assume that people can work out the difference, because, y'know, > Bill knows the difference, and Roy does, so obviously, all the rest of > us should too. Actually; the command is usually apachectl ;-)
ProxyPreserveHost per dir??
Is there a particular reason why ProxyPreserveHost is per server and not per dir? We have some "unusual" configs and I'm wondering what secret internals I may be breaking by changing that? The code didn't show anything obvious. -- Brian Akins
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On Tue, Mar 16, 2010 at 8:05 PM, William A. Rowe Jr. wrote: > On 3/16/2010 12:37 PM, Noirin Shirley wrote: >> >> In some places, we use httpd, but that leads to some horrible >> confusion between the product and the command. > > I guess I'm not seeing the disconnect. If a reader cannot parse httpd > as shorthand "the Apache HTTP Server program", then we have more serious > issues in helping them become a web server administrator. The problem is that httpd is used as shorthand for "the Apache HTTP Server" *and* as a reference to a specific binary/process/command, and we assume that people can work out the difference, because, y'know, Bill knows the difference, and Roy does, so obviously, all the rest of us should too. If the command were, say, "apache2", then just using "Apache HTTP Server (httpd)" for the first mention, and "httpd" thereafter would be fine. Heck, even if we absolutely always used "apachectl", and never referred to the binary directly, we might be able to get something that worked, although there'd be a lot more rewriting of docs required. But when it's not always clear to people who've been working on the project for years whether a given instance of "httpd" refers to a single binary or a set of binaries, and config files, and sometimes other bits and pieces, how on earth do we expect users to be able to grok what we're talking about? And as for clueless lawyers, unless we've given one commit access, they're not the only ones using HTTPd either - cf http://httpd.apache.org/docs/2.2/install.html Noirin
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On 3/16/2010 12:37 PM, Noirin Shirley wrote: > > In some places, we use httpd, but that leads to some horrible > confusion between the product and the command. I guess I'm not seeing the disconnect. If a reader cannot parse httpd as shorthand "the Apache HTTP Server program", then we have more serious issues in helping them become a web server administrator. I was a bit confused in this commit message w.r.t. "concensus". Noirin and yourself clearly take one view, Roy and I have expounded a very contrary view, and I haven't see the rest of this dialog (following dev@, docs@, users@ etc).
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On Tue, Mar 16, 2010 at 6:24 PM, Roy T. Fielding wrote: > On Mar 16, 2010, at 5:48 AM, rbo...@apache.org wrote: > >> Author: rbowen >> Date: Tue Mar 16 12:48:31 2010 >> New Revision: 923712 >> >> URL: http://svn.apache.org/viewvc?rev=923712&view=rev >> Log: >> In as much as we can be said to have consensus on anything at all, we >> appear to have consensus that we will refer to the product (in the >> documentation) as Apache HTTPD, or HTTPD for short, and to the server >> binary executable as httpd. Here's a few changes to that >> effect. > > I thought the only people who ever capitalize HTTP in httpd are > clueless lawyers. httpd is the product name. We've never been even remotely consistent about the name of the product. In some places, we use httpd, but that leads to some horrible confusion between the product and the command. In other places, we use Apache HTTP Server, but then when we switch to httpd because it's less wordy or fits the sentence better, it's not at all clear that httpd and Apache HTTP Server mean the same thing. In a few places, we use Apache Web Server, just for variety (and, I've heard it argued, because it can serve over more than just HTTP). > It is not, and never > has been, HTTPD, HTTPd, or any other misspelling of d. It's that > bloody thing we put in the package name, like I don't really see how the package name proves anything - Tomcat packages have names like apache-tomcat-5.5.28.tar.gz, but I've never been called clueless (or a lawyer) for capitalising the project name differently to the package name. Sure, httpd makes sense as an all-small command. But I see no reason that it's stupid to distinguish between the command and the product, and nothing you've said convinces me that HTTPD or HTTPD or Httpd or any other product name that removes the ambiguity is any worse than calling the product "Web Server". Noirin
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On Mar 16, 2010, at 5:48 AM, rbo...@apache.org wrote: > Author: rbowen > Date: Tue Mar 16 12:48:31 2010 > New Revision: 923712 > > URL: http://svn.apache.org/viewvc?rev=923712&view=rev > Log: > In as much as we can be said to have consensus on anything at all, we > appear to have consensus that we will refer to the product (in the > documentation) as Apache HTTPD, or HTTPD for short, and to the server > binary executable as httpd. Here's a few changes to that > effect. WTF? -1 I thought the only people who ever capitalize HTTP in httpd are clueless lawyers. httpd is the product name. It is not, and never has been, HTTPD, HTTPd, or any other misspelling of d. It's that bloody thing we put in the package name, like httpd-2.2.15.tar.gz which should really be apache-httpd-2.2.15.tar.gz but that's another discussion. Roy
Re: Client authentication and authorization using client certificates
Johannes great news, mod_auth_certificate works ! I reckon you need => httpd-2.2.14 in order to use the UID. See BUG https://issues.apache.org/bugzilla/show_bug.cgi?id=45107 Initially I decided to wait for Fedora 13 with httpd-2.2.14 where they say the above BUG is fixed in HTTPD. In the end I tested with an unofficial version of httpd-2.2.14 on Fedora 12. Good work, Dave --- Johannes Müller wrote: > > Eric Covener wrote: >> On Tue, Jun 16, 2009 at 5:40 PM, Johannes Müller wrote: >> >>> Yes should be no problem. Relicensing means I'll also have to remove >>> current >>> the current >>> version and SVN revisions so there is no problem if someone already >>> downloaded the >>> GPLed release? >>> >> >> IANAL: I don't see why, they're free to use it under those terms, and >> you're free to change the terms of any subsequent release (or prior >> release to other parties!) >> >> > > > Released version 0.2 of mod_auth_certificate under Apache License 2.0 > Download at https://sourceforge.net/projects/modauthcertific/ > > Any comments? > > Greetings, > Johannes > > -- View this message in context: http://old.nabble.com/Client-authentication-and-authorization-using-client-certificates-tp24058416p27919447.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: svn commit: r923429 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
On 15.03.2010 21:46, s...@apache.org wrote:
> Author: sf
> Date: Mon Mar 15 20:46:26 2010
> New Revision: 923429
>
> URL: http://svn.apache.org/viewvc?rev=923429&view=rev
> Log:
> get the socket with ap_get_module_config instead of walking the filter chain
>
> Modified:
> httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
>
> Modified: httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_reqtimeout.c?rev=923429&r1=923428&r2=923429&view=diff
> ==
> --- httpd/httpd/trunk/modules/filters/mod_reqtimeout.c (original)
> +++ httpd/httpd/trunk/modules/filters/mod_reqtimeout.c Mon Mar 15 20:46:26
> 2010
> @@ -151,21 +151,7 @@ static apr_status_t reqtimeout_filter(ap
> }
>
> if (!ccfg->socket) {
> -core_net_rec *net_rec;
> -ap_filter_t *core_in = f->next;
> -
> -while (core_in && core_in->frec != ap_core_input_filter_handle)
> -core_in = core_in->next;
> -
> -if (!core_in) {
> -ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, f->c,
> - "mod_reqtimeout: Can't get socket "
> - "handle from core_input_filter");
> -ap_remove_input_filter(f);
> -return ap_get_brigade(f->next, bb, mode, block, readbytes);
> -}
> -net_rec = core_in->ctx;
> -ccfg->socket = net_rec->client_socket;
> +ccfg->socket = ap_get_module_config(f->c->conn_config, &core_module);
Not quite sure if this data structure is part of the API. If not the core could
change it anytime and the above assignment could fail then.
Regards
Rüdiger
