httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: related config directives
Date Thu, 20 Dec 2001 20:32:07 GMT
On Thu, Dec 20, 2001 at 03:22:33PM -0500, Greg Ames wrote:
> ...are more painful to deal with than you might think, if the user is
> allowed to code them in any order.  
> I'd like the comparisons between MaxClients and ServerLimit and the
> equivalent thread directives to be coding order insensitive.  So I
> created a post-config hook to do the comparing & adjusting.  The code
> was very simple, but the log messages went to the error log file twice,
> rather than to the console once which is what people are accustomed to
> for config errors.
> worker already has the same situation with MaxClients and
> ThreadsPerChild.  It has a clever but kind of scary solution:  a
> pre-config hook which swaps nodes in the config tree if it doesn't like
> the order.  Then the comparisons, adjusting, and logging are done when
> the second directive is parsed.  
> While I think it's a very cool hack, mucking with the innards of the
> config tree bothers me some.  config.c could provide an API to do order
> checking and swapping, but I can't see this as a general solution. 
> Think about cases where one directive is in container X and the other
> isn't - yuck!

I agree (and I'm the one who wrote it).

> What if the very first ap_run_post_config hook was moved to before the
> logs files were opened?  Then we could have simple logic to compare or
> otherwise process multiple directives.  Any error messages would go
> directly to the console.  If you wanted them to also go to the error log
> file, that would just happen during the second post-config call;  if you
> don't want that, it's easy to avoid.

I was thinking the same thing. My only concern was that something has
already been written that assumes post_config already has the log opened
and stderr redirected. Unless that is a problem or someone else can
come up with another reason not to do this, I'm +1.

Another possibility that would avoid the whole issue altogether would
be to simply add another hook before open_logs. I started doing this
yesterday on the plane:

Index: server/main.c
RCS file: /home/cvs/httpd-2.0/server/main.c,v
retrieving revision 1.111
diff -u -u -r1.111 main.c
--- server/main.c	2001/12/18 20:26:15	1.111
+++ server/main.c	2001/12/20 20:31:52
@@ -412,6 +412,10 @@
 	destroy_and_exit_process(process, 0);
+    if ( ap_run_validate_config(pconf, plog, ptemp, server_conf) != OK) {
to validate the config\n");
+        destroy_and_exit_process(process, 1);
+    }
     if ( ap_run_open_logs(pconf, plog, ptemp, server_conf) != OK) {
to open logs\n");
         destroy_and_exit_process(process, 1);
Index: include/http_config.h
RCS file: /home/cvs/httpd-2.0/include/http_config.h,v
retrieving revision 1.92
diff -u -u -r1.92 http_config.h
--- include/http_config.h	2001/11/24 00:08:29	1.92
+++ include/http_config.h	2001/12/20 20:31:55
@@ -974,6 +974,18 @@
 AP_DECLARE_HOOK(void,pre_config,(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp))
+ * Run the validate_config function for each module. This function should
+ * validate the config parameters accepted by the module, and return
+ * OK or non-OK to signify success.
+ * @param pconf The config pool
+ * @param plog The logging streams pool
+ * @param ptemp The temporary pool
+ * @param s The list of server_recs
+ * @return OK or DECLINED on success anything else is a error
+ */
+AP_DECLARE_HOOK(int,validate_config,(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp,server_rec
  * Run the post_config function for each module
  * @param pconf The config pool
  * @param plog The logging streams pool


View raw message