Re: Error codes
Just to be pedantic... even lazy consensus isn't that fast (3days), but no big deal since we are CTR... On Dec 2, 2011, at 6:33 PM, Stefan Fritsch wrote: On Thursday 01 December 2011, Stefan Fritsch wrote: Any more comments/thoughts? As nobody disagreed, this is now in trunk. I intend to commit it to 2.4 tomorrow. It's already a big step forward and the finishing touches can be done in 2.4.1.
Re: Error codes
On Thursday 01 December 2011, Stefan Fritsch wrote: Any more comments/thoughts? As nobody disagreed, this is now in trunk. I intend to commit it to 2.4 tomorrow. It's already a big step forward and the finishing touches can be done in 2.4.1.
Re: Error codes
On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. Actually I currently have two scripts, one that tries to identify where to add a number and adds AH, and another one that takes each AH and replaces it with the next free number. So programmers would only need to add AH and run the second script over the source file. The only disadvantage may be that in a list sorted by log number, messages by the same module would not appear next to each other. On the other hand, it should be easy to extend the script to also create a list sorted by module or source file name if that is useful. another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Sometimes we move code from the core to a module or vice versa. If the code is mostly unchanged, I would want to keep the error message number in this case. So best not encode that in the number, IMHO. If we ever hit the codes, we could either switch to hex or add another digit. Or would it be better to use 5 digits right away? Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); which would not produce a hit for AH0815. Thoughts?
Re: Error codes
On Wednesday 30 November 2011, Mikhail T. wrote: On 29.11.2011 23:30, William A. Rowe Jr. wrote: But my point remains, that we allocate each module a block of some 50 codes, such that mod_aaa gets AHM-0049 and mod_aab gets 50-99, etc. How will 3rd-party modules be getting their blocks? One idea would be to have them use other prefixes than AH. But this may be a bad idea if we ever want the number to be used for other things.
Re: Error codes
ap_log_error(..., APLOGNO(0815) foo went wrong, ...); great idea on avoiding svn.a.o search hits.
Re: Error codes
On Wed, Nov 30, 2011 at 01:09, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. Actually I currently have two scripts, one that tries to identify where to add a number and adds AH, and another one that takes each AH and replaces it with the next free number. So programmers would only need to add AH and run the second script over the source file. The only disadvantage may be that in a list sorted by log number, messages by the same module would not appear next to each other. On the other hand, it should be easy to extend the script to also create a list sorted by module or source file name if that is useful. another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Sometimes we move code from the core to a module or vice versa. If the code is mostly unchanged, I would want to keep the error message number in this case. So best not encode that in the number, IMHO. If we ever hit the codes, we could either switch to hex or add another digit. Or would it be better to use 5 digits right away? Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); which would not produce a hit for AH0815. Thoughts? Any reason *not* to use 5 digits? -- Sent from my toaster.
Re: Error codes
On 11/30/2011 2:09 AM, Stefan Fritsch wrote: Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); +1 To me, this is a must. This also adds a somewhat handy anchor when searching for log entries in code that may or may not span multiple lines. -- Daniel Ruggeri
Re: Proposal: error codes
On 27 Nov 2011, at 17:14, Stefan Fritsch wrote: Yes, that would be a good idea and I agree with Daniel that we should use a distinct prefix or format. We currently have around 2700 calls to *_log_?error in trunk, so a 4-digit number should be ok. Together with for example AH as prefix for Apache HTTPD this would result in numbers like AH0815 which don't seem to cause many hits on google. I think most people still use file logging, but Apache httpd does also support syslog. And over the life of Apache httpd syslog has gained features too, such as message codes. http://tools.ietf.org/html/rfc5424 section 6.2.7 says: The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID TCPIN for incoming TCP traffic and the MSGID TCPOUT for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on a relay or collector. There is also a mechanism for structured metadata. I don't know whether either or both of these will be written into future Apache httpd… but I thought it was worth mentioning these early on in the discussion. -- Tim Bannister – is...@jellybaby.net
Re: Error codes
On 11/30/2011 2:09 AM, Stefan Fritsch wrote: On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. You need room for expansion. We will add messages :) If you produced a sequential list of error codes, wouldn't it be more sensical to have all mod_authnz_ldap errors in a contiguous list? I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them.
Re: Error codes
On 30 Nov 2011, at 9:21 PM, William A. Rowe Jr. wrote: I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them. From my experience, any attempt at grouping some kind of numbering like this normally results a few years later in an attempt to undo the grouping to solve problems caused by the ranges being too small, or running out of numbers of a sensible size. Ideally it should be as simple as possible, run a script and a number will be chosen for you is a lot more convenient, and if a script could warn of duplicated numbers for fixing (think the result of cut-and-paste by someone unfamiliar with the script) that would be ideal too. Regards, Graham --
Re: Error codes
On Nov 30, 2011, at 3:23 AM, HyperHacker wrote: Any reason *not* to use 5 digits? The extra character, or using hex, seems worth the future flexibility. We want to be able to assign new codes, rather than reusing old ones, when error messages change in future versions. Allocating 50 messages to mod_foo might be fine for now, but in httpd version 4.8 we may have all new messages. Not sure we can adequately determine how many is enough to allocate. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Proposal: error codes
On Wednesday 30 November 2011, Tim Bannister wrote: On 27 Nov 2011, at 17:14, Stefan Fritsch wrote: Yes, that would be a good idea and I agree with Daniel that we should use a distinct prefix or format. We currently have around 2700 calls to *_log_?error in trunk, so a 4-digit number should be ok. Together with for example AH as prefix for Apache HTTPD this would result in numbers like AH0815 which don't seem to cause many hits on google. I think most people still use file logging, but Apache httpd does also support syslog. And over the life of Apache httpd syslog has gained features too, such as message codes. http://tools.ietf.org/html/rfc5424 section 6.2.7 says: The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID TCPIN for incoming TCP traffic and the MSGID TCPOUT for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on a relay or collector. There is also a mechanism for structured metadata. I don't know whether either or both of these will be written into future Apache httpd… but I thought it was worth mentioning these early on in the discussion. That's definitely interesting to know, but one has to see if there is a standard API for these things. The Linux man pages of syslog() and friends do not mention MSGID.
Re: Error codes
On Wednesday 30 November 2011, Graham Leggett wrote: On 30 Nov 2011, at 9:21 PM, William A. Rowe Jr. wrote: I'm not suggesting changing the alpha prefix. Just block out ranges so that any listing of the codes is grouped by module that emits them. From my experience, any attempt at grouping some kind of numbering like this normally results a few years later in an attempt to undo the grouping to solve problems caused by the ranges being too small, or running out of numbers of a sensible size. I agree with Graham here. mod_ssl has 300 messages, so the range per module would likely need to be something like 1000, and with 100 modules, this would mean 6 digits in the number. And tracking one counter per module would make my script way more complex. Ideally it should be as simple as possible, run a script and a number will be chosen for you is a lot more convenient, and if a script could warn of duplicated numbers for fixing (think the result of cut-and-paste by someone unfamiliar with the script) that would be ideal too. The current state is here: http://people.apache.org/~sf/log-msg-numbers.diff http://people.apache.org/~sf/log-msg-numbers.list http://people.apache.org/~sf/log-msg-numbers.scripts.diff Changes to previous are - 5 digits instead of 4 - with APLOGNO() syntax (we really want that, just think of all the archives of the svn commit mailing list) - level debug and above instead of info - now after the s/r/c/p argument and not before the format; this makes the script a bit simpler and don't miss logging calls with multi-line format strings. But the number is now frequently on a different line than the format string. I have put the scripts there, too, but they need some cleaning up. Still todo are at least ap_log_cserror, ssl_log_error, dav_log_err, and everything that has a variable as level parameter. What to do about multi-line log messages that are split over several calls to ap_log...()? Grep prefork.c for 'almost certain server failure' for an example. Maybe just add a number to the first line? This is something that will need manual adjustment. I guess before we commit this to 2.4, all other pending backports should be done. Any more comments/thoughts?
Re: Error codes
On 01 Dec 2011, at 1:28 AM, Stefan Fritsch wrote: I guess before we commit this to 2.4, all other pending backports should be done. Speaking for myself, all my backports are done. Regards, Graham --
Re: Proposal: error codes
On 11/27/2011 8:34 AM, Rich Bowen wrote: At Apachecon several of us were discussing how error messages could be made more helpful without making them paragraphs. Two suggestions were made - adding a URL to the message or adding a number/code to each error that would then be looked up for more information. Any thoughts on 1) the wisdom of this and 2) the method of assigning codes? Keep these numeric and it will assist us in later internationalizing error log messages. I was initially thinking in terms of using hashed strings into mapping indexes, but such numeric codes would be valuable. Ideally we could assign these numbers into the appropriate apr_errno range. From the docs... /** * APR_OS_START_USERERR are reserved for applications that use APR that * layer their own error codes along with APR's. Note that the * error immediately following this one is set ten times farther * away than usual, so that users of apr have a lot of room in * which to declare custom error codes. * * In general applications should try and create unique error codes. To try * and assist in finding suitable ranges of numbers to use, the following * ranges are known to be used by the listed applications. If your * application defines error codes please advise the range of numbers it * uses to d...@apr.apache.org for inclusion in this list. * * Ranges shown are in relation to APR_OS_START_USERERR * * Subversion - Defined ranges, of less than 100, at intervals of 5000 * starting at an offset of 5000, e.g. * +5000 to 5100, +1 to 10100 */ APR_OS_START_USERERR starts at 7 through 569. As the SVN hints suggest, we would probably want to block out 7-79 for core errs, then 8- in small blocks for individual modules.
Re: Proposal: error codes
On Tuesday 29 November 2011, William A. Rowe Jr. wrote: On 11/27/2011 8:34 AM, Rich Bowen wrote: At Apachecon several of us were discussing how error messages could be made more helpful without making them paragraphs. Two suggestions were made - adding a URL to the message or adding a number/code to each error that would then be looked up for more information. Any thoughts on 1) the wisdom of this and 2) the method of assigning codes? Keep these numeric and it will assist us in later internationalizing error log messages. I was initially thinking in terms of using hashed strings into mapping indexes, but such numeric codes would be valuable. Well, the number/code will be a number with some prefix (e.g. AH) for search machine friendliness. The number could later potentially be used for looking up translations, but not without API changes. And I am not sure if that would be the smartest idea. Two log messages that contain exactly the same text but are emitted by different parts of httpd should have two distinct numbers. This may not be the best way to handle translations. For 2.4, I would pass the number as part of the format string. This does not require any code change (in the sense of programming logic) and is therefore still doable in 2.4. Ideally we could assign these numbers into the appropriate apr_errno range. I think this is kind of orthogonal to having numbers in each log message. There is often an APR error code that supplements the log message. The log message says what went wrong and the error code says how it went wrong (e.g. message is Can't open file %s, error code is ENOENT). But we don't want the error strings for APR error codes to be format strings. The number of the log message however could be listed in the documentation saying that this message happens if a client requests a non-existing URL. On the other hand, we could of course make httpd APIs return httpd- specific apr_errno values that could then be passed in the usual apr_status_t argument to ap_log_*error and be printed like normal APR error messages. But maybe your and Mikhail's mails are showing that we should have some name for these error message numbers that allows to distinguish them from error codes as those returned by system or library calls. Maybe message tag or error tag?
Re: Error codes
On Monday 28 November 2011, Rich Bowen wrote: On Nov 28, 2011, at 11:21 AM, Stefan Fritsch wrote: A question on procedure: Do you want to add all error codes at once and then fill in the descriptions or add the error codes as the documentation evolves? If the former, some scripting would probably save a lot of work, too. If it can be done all at once with a script, that would be great. The only concern from there would be the ease of applying that change to earlier versions. Presumably the trunk - 2.4 patch would work pretty well, but - 2.2 would take a lot of work. Not sure that it would be worth it, though. I'm in favor of making this a 2.4-only effort. I am not sure that every debug message needs a code, maybe one could at first only tag those of level info or higher? Or maybe even warning? Ah. Good point. Yes, we should probably skip stuff in Debug, unless it makes sense to add them on a case-by-case basis later on. (Not sure what would justify that, but perhaps some messages are more common than others? More important? More … something.) I would say warn and higher, but perhaps it merits further discussion. Adding them to info now might save hassle later on if we wanted to further document those, and costs us nothing now, except for 6 characters in the log message. What do folks think? Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. The script still misses all occurences where the format string is split into several parts (e.g. over several lines), where the loglevel is not constant but a variable, and possibly some others. Are other folks comfortable with going this way? Add it to 2.4?
Re: Error codes
On Nov 29, 2011, at 6:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. The script still misses all occurences where the format string is split into several parts (e.g. over several lines), where the loglevel is not constant but a variable, and possibly some others. Are other folks comfortable with going this way? Add it to 2.4? +1 -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Error codes
On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion?
Re: Error codes
Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Gün.
Re: Error codes
On 11/29/2011 8:58 PM, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... But my point remains, that we allocate each module a block of some 50 codes, such that mod_aaa gets AHM-0049 and mod_aab gets 50-99, etc.
Re: Error codes
On 29.11.2011 23:30, William A. Rowe Jr. wrote: But my point remains, that we allocate each module a block of some 50 codes, such that mod_aaa gets AHM-0049 and mod_aab gets 50-99, etc. How will 3rd-party modules be getting their blocks? -mi
Re: Proposal: error codes
Am 27.11.2011 18:14, schrieb Stefan Fritsch: Yes, that would be a good idea and I agree with Daniel that we should use a distinct prefix or format. We currently have around 2700 calls to *_log_?error in trunk, so a 4-digit number should be ok. Together with for example AH as prefix for Apache HTTPD this would result in numbers like AH0815 which don't seem to cause many hits on google. +1 - sounds good. Gün.
Re: Proposal: error codes
On 27.11.2011 12:14, Stefan Fritsch wrote:
Yes, that would be a good idea and I agree with Daniel that we should
use a distinct prefix or format. We currently have around 2700 calls
to *_log_?error in trunk, so a 4-digit number should be ok. Together
with for example AH as prefix for Apache HTTPD this would result in
numbers like AH0815 which don't seem to cause many hits on google.
I'd like to suggest, the codes be 8-character (or shorter) words and declared as
something like:
union apr_error_code {
uint64_ti;
chars[8];
};
This way the code itself can contain a meaningful short-string (printable and
human-readable):
but different codes can still be assigned and compared without a special
function:
if (code.i) {
log(Attempt to foo returned: %.8s, code.s);
}
The actual numbers may differ between platforms of different endianness, but who
cares -- as long as the character strings themselves remain the same and
meaningful... Yours,
-mi
Proposal: error codes
At Apachecon several of us were discussing how error messages could be made more helpful without making them paragraphs. Two suggestions were made - adding a URL to the message or adding a number/code to each error that would then be looked up for more information. Any thoughts on 1) the wisdom of this and 2) the method of assigning codes? I've long considered error messages to be documentation and would live to see the log files be one step more helpful. -- Rich Bowen rbo...@rcbowen.com
Re: Proposal: error codes
On 11/27/2011 8:34 AM, Rich Bowen wrote: At Apachecon several of us were discussing how error messages could be made more helpful without making them paragraphs. Two suggestions were made - adding a URL to the message or adding a number/code to each error that would then be looked up for more information. Any thoughts on 1) the wisdom of this and 2) the method of assigning codes? I've long considered error messages to be documentation and would live to see the log files be one step more helpful. -- Rich Bowen rbo...@rcbowen.com This sounds like a cool idea. I think making the error code something distinct that a crawler on the web would find is important - making it that much easier for someone who plugs in the error message they get into their favorite search engine. A good example, though probably not intentional, are some of the error messages thrown in openssl. Because those strings just don't show up by accident on the web, it makes finding those error numbers a bit less of a chore... and with having real documentation behind them, might actually be helpful unlike some of those many I get this error, please help messages on the web. Also, we should consider format. Wiki or doc? There are so many messages that could be thrown that crowdsourcing the documentation for it may allow us to cover more bases. -- Daniel Ruggeri
Re: Proposal: error codes
On Sunday 27 November 2011, Rich Bowen wrote: At Apachecon several of us were discussing how error messages could be made more helpful without making them paragraphs. Two suggestions were made - adding a URL to the message or adding a number/code to each error that would then be looked up for more information. Any thoughts on 1) the wisdom of this and 2) the method of assigning codes? I've long considered error messages to be documentation and would live to see the log files be one step more helpful. Yes, that would be a good idea and I agree with Daniel that we should use a distinct prefix or format. We currently have around 2700 calls to *_log_?error in trunk, so a 4-digit number should be ok. Together with for example AH as prefix for Apache HTTPD this would result in numbers like AH0815 which don't seem to cause many hits on google. As a first step, one could simply manually add the error code to the format strings of those messages that frequently appear in support requests. This would be non-disruptive for 2.4 and could even be done in some future 2.2.x version, if someone is willing to do the work. I would keep the scheme for assigning codes simple. Just have a file that contains the next usable one and always increment the number in that file when a code is assigned to an error message. We could then have some scripts to check that no error code is used twice and maybe create a list of error message and module for each error code. If somebody later comes up with something more refined (e.g. pass the error code as additional parameter to ap_log_error), it should be straightforward enough to switch. Cheers, Stefan
Re: Proposal: error codes
On Nov 27, 2011, at 12:14, Stefan Fritsch s...@sfritsch.de wrote: Yes, that would be a good idea and I agree with Daniel that we should use a distinct prefix or format. We currently have around 2700 calls to *_log_?error in trunk, so a 4-digit number should be ok. Together with for example AH as prefix for Apache HTTPD this would result in numbers like AH0815 which don't seem to cause many hits on google. As a first step, one could simply manually add the error code to the format strings of those messages that frequently appear in support requests. This would be non-disruptive for 2.4 and could even be done in some future 2.2.x version, if someone is willing to do the work. Yes, I'm willing to do the work, as are some folks on the docs list. I expect we'd start drafting the doc in the wiki and move it to the formal docs once it's more fully done. Thanks for the suggestion of the odd format. That seems very reasonable.
Re: Proposal: error codes
On Nov 27, 2011, at 12:58, Rich Bowen rbo...@rcbowen.com wrote: Thanks for the suggestion of the odd format. That seems very reasonable. Clearly I need to stop writing email on my phone. The CODE format.
How to return HTTP error codes using hook filter ...
I've created a filter using ap_hook_handler(hook_handler_wmserr, NULL, NULL, APR_HOOK_FIRST). This filter does some sanity checks, and if something is wrong should respond to the requester with an XML message containing the error details, and return HTTP_BAD_REQUEST; /* 400 */ However, apache will respond with the default HTTP_BAD_REQUEST message text and ignore the changes I make calling the ap_set_content_type() and ap_rprintf() routines. Unless I return 0 then it works fine, except the result is 200 OK when it should be 400 Bad request. How can I change the body and indicate the error code which should be returned? -- Kiffin Gish | Desktop Services Development | TomTom | [EMAIL PROTECTED] | +31 (0) 6 15529214 mobile | +31 (0) 20 850 0989 office This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
[PATCH] allow pre_config to return error codes and prevent startup
I have the need to return and detect errors from the pre_config phase.
I'd like this mostly for detecting apr_proc_detach errors, but this will
be useful in other places too. (Something tells me we should have done
this in all the RUN_ALL-type hooks).
Here's a patch that implements it. It seems to work fine on Solaris
and Linux and will probably work everywhere else unless there's a typo.
Does anyone see a reason not to apply this?
-aaron
Index: modules/arch/netware/mod_nw_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/arch/netware/mod_nw_ssl.c,v
retrieving revision 1.3
diff -u -u -r1.3 mod_nw_ssl.c
--- modules/arch/netware/mod_nw_ssl.c 23 Nov 2001 16:35:21 - 1.3
+++ modules/arch/netware/mod_nw_ssl.c 28 Jan 2002 23:10:42 -
@@ -334,10 +334,12 @@
return APR_SUCCESS;
}
-static void nwssl_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
+static int nwssl_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp)
{
ap_seclisteners = NULL;
+
+return OK;
}
static int nwssl_post_config(apr_pool_t *pconf, apr_pool_t *plog,
Index: modules/experimental/mod_example.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_example.c,v
retrieving revision 1.31
diff -u -u -r1.31 mod_example.c
--- modules/experimental/mod_example.c 10 Jan 2002 09:20:28 - 1.31
+++ modules/experimental/mod_example.c 28 Jan 2002 23:10:46 -
@@ -847,13 +847,15 @@
* This routine is called before the server processes the configuration
* files. There is no return value.
*/
-static void x_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
- apr_pool_t *ptemp)
+static int x_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
+apr_pool_t *ptemp)
{
/*
* Log the call and exit.
*/
trace_add(NULL, NULL, NULL, x_pre_config());
+
+return OK;
}
/*
Index: modules/loggers/mod_log_config.c
===
RCS file: /home/cvs/httpd-2.0/modules/loggers/mod_log_config.c,v
retrieving revision 1.76
diff -u -u -r1.76 mod_log_config.c
--- modules/loggers/mod_log_config.c10 Jan 2002 03:23:33 - 1.76
+++ modules/loggers/mod_log_config.c28 Jan 2002 23:10:48 -
@@ -1194,7 +1194,7 @@
apr_hash_set(log_hash, tag, 1, (const void *)log_struct);
}
-static void log_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
+static int log_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
{
static APR_OPTIONAL_FN_TYPE(ap_register_log_handler) *log_pfn_register;
@@ -1229,6 +1229,8 @@
log_pfn_register(p, U, log_request_uri, 1);
log_pfn_register(p, s, log_status, 1);
}
+
+return OK;
}
static void register_hooks(apr_pool_t *p)
Index: modules/metadata/mod_headers.c
===
RCS file: /home/cvs/httpd-2.0/modules/metadata/mod_headers.c,v
retrieving revision 1.35
diff -u -u -r1.35 mod_headers.c
--- modules/metadata/mod_headers.c 8 Nov 2001 23:26:36 - 1.35
+++ modules/metadata/mod_headers.c 28 Jan 2002 23:10:50 -
@@ -605,12 +605,14 @@
h = tag_handler;
apr_hash_set(format_tag_hash, tag, 1, h);
}
-static void header_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
+static int header_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
{
format_tag_hash = apr_hash_make(p);
register_format_tag_handler(p, D, (void*) header_request_duration, 0);
register_format_tag_handler(p, t, (void*) header_request_time, 0);
register_format_tag_handler(p, e, (void*) header_request_env_var, 0);
+
+return OK;
}
static void register_hooks(apr_pool_t *p)
Index: modules/ssl/mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.42
diff -u -u -r1.42 mod_ssl.c
--- modules/ssl/mod_ssl.c 29 Nov 2001 07:07:36 - 1.42
+++ modules/ssl/mod_ssl.c 28 Jan 2002 23:10:52 -
@@ -204,7 +204,7 @@
* the various processing hooks
*/
-static void ssl_hook_pre_config(
+static int ssl_hook_pre_config(
apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp)
{
/* Register us to handle mod_log_config %c/%x variables */
@@ -215,6 +215,8 @@
/* XXX: Register us to handle mod_status extensions that don't exist yet */
ssl_scache_status_register(pconf);
#endif /* -0- */
+
+return OK;
}
static int ssl_hook_pre_connection(conn_rec *c)
Index: server/config.c
===
RCS file: /home/cvs/httpd-2.0/server/config.c,v
retrieving revision 1.143
diff -u -u -r1.143 config.c
--- server/config.c 2 Jan 2002 23:27:57 - 1.143
+++ server/config.c 28
Re: [PATCH] allow pre_config to return error codes and prevent startup
Aaron Bannert [EMAIL PROTECTED] writes: I have the need to return and detect errors from the pre_config phase. I'd like this mostly for detecting apr_proc_detach errors, but this will be useful in other places too. (Something tells me we should have done this in all the RUN_ALL-type hooks). go for it Here's a patch that implements it. It seems to work fine on Solaris and Linux and will probably work everywhere else unless there's a typo. in which case it will be caught and fixed before long -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] allow pre_config to return error codes and prevent startup
Sounds reasonable to me.
Bill
I have the need to return and detect errors from the pre_config phase.
I'd like this mostly for detecting apr_proc_detach errors, but this will
be useful in other places too. (Something tells me we should have done
this in all the RUN_ALL-type hooks).
Here's a patch that implements it. It seems to work fine on Solaris
and Linux and will probably work everywhere else unless there's a typo.
Does anyone see a reason not to apply this?
-aaron
Index: modules/arch/netware/mod_nw_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/arch/netware/mod_nw_ssl.c,v
retrieving revision 1.3
diff -u -u -r1.3 mod_nw_ssl.c
--- modules/arch/netware/mod_nw_ssl.c 23 Nov 2001 16:35:21 - 1.3
+++ modules/arch/netware/mod_nw_ssl.c 28 Jan 2002 23:10:42 -
@@ -334,10 +334,12 @@
return APR_SUCCESS;
}
-static void nwssl_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
+static int nwssl_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp)
{
ap_seclisteners = NULL;
+
+return OK;
}
static int nwssl_post_config(apr_pool_t *pconf, apr_pool_t *plog,
Index: modules/experimental/mod_example.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_example.c,v
retrieving revision 1.31
diff -u -u -r1.31 mod_example.c
--- modules/experimental/mod_example.c 10 Jan 2002 09:20:28 - 1.31
+++ modules/experimental/mod_example.c 28 Jan 2002 23:10:46 -
@@ -847,13 +847,15 @@
* This routine is called before the server processes the configuration
* files. There is no return value.
*/
-static void x_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
- apr_pool_t *ptemp)
+static int x_pre_config(apr_pool_t *pconf, apr_pool_t *plog,
+apr_pool_t *ptemp)
{
/*
* Log the call and exit.
*/
trace_add(NULL, NULL, NULL, x_pre_config());
+
+return OK;
}
/*
Index: modules/loggers/mod_log_config.c
===
RCS file: /home/cvs/httpd-2.0/modules/loggers/mod_log_config.c,v
retrieving revision 1.76
diff -u -u -r1.76 mod_log_config.c
--- modules/loggers/mod_log_config.c 10 Jan 2002 03:23:33 - 1.76
+++ modules/loggers/mod_log_config.c 28 Jan 2002 23:10:48 -
@@ -1194,7 +1194,7 @@
apr_hash_set(log_hash, tag, 1, (const void *)log_struct);
}
-static void log_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
+static int log_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
{
static APR_OPTIONAL_FN_TYPE(ap_register_log_handler) *log_pfn_register;
@@ -1229,6 +1229,8 @@
log_pfn_register(p, U, log_request_uri, 1);
log_pfn_register(p, s, log_status, 1);
}
+
+return OK;
}
static void register_hooks(apr_pool_t *p)
Index: modules/metadata/mod_headers.c
===
RCS file: /home/cvs/httpd-2.0/modules/metadata/mod_headers.c,v
retrieving revision 1.35
diff -u -u -r1.35 mod_headers.c
--- modules/metadata/mod_headers.c 8 Nov 2001 23:26:36 - 1.35
+++ modules/metadata/mod_headers.c 28 Jan 2002 23:10:50 -
@@ -605,12 +605,14 @@
h = tag_handler;
apr_hash_set(format_tag_hash, tag, 1, h);
}
-static void header_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
+static int header_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
{
format_tag_hash = apr_hash_make(p);
register_format_tag_handler(p, D, (void*) header_request_duration, 0);
register_format_tag_handler(p, t, (void*) header_request_time, 0);
register_format_tag_handler(p, e, (void*) header_request_env_var, 0);
+
+return OK;
}
static void register_hooks(apr_pool_t *p)
Index: modules/ssl/mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.42
diff -u -u -r1.42 mod_ssl.c
--- modules/ssl/mod_ssl.c 29 Nov 2001 07:07:36 - 1.42
+++ modules/ssl/mod_ssl.c 28 Jan 2002 23:10:52 -
@@ -204,7 +204,7 @@
* the various processing hooks
*/
-static void ssl_hook_pre_config(
+static int ssl_hook_pre_config(
apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp)
{
/* Register us to handle mod_log_config %c/%x variables */
@@ -215,6 +215,8 @@
/* XXX: Register us to handle mod_status extensions that don't exist yet */
ssl_scache_status_register(pconf);
#endif /* -0- */
+
+return OK;
}
static int ssl_hook_pre_connection(conn_rec *c)
Index: server/config.c
===
RCS file: /home/cvs/httpd-2.0/server/config.c,v
retrieving revision 1.143
diff -u -u -r1.143 config.c
