The current mod_log_config has a very limited capability for support of log writers other than the build-in file/pipe writer. This is a bit bad since some people would like to log somewhere else (usually some kind of database), all data or only parts thereof, as an exclusive log target or in addition to the standard files. Currently, there can be only one writer and it has to deal with whatever string mod_log_config assembles for him. The other possibility would be to bypass mod_log_config completely and thus reinventing the wheel. In any case, a number of configuration directives have to be added, all doing more or less the same two things: specifying a target and a format. This variant of mod_log_config allows an unlimited number of external log writers to be added. The log writers can be used simultanously, their basic configuration is done through mod_log_config's CustomLog and LogFormat directives and they have full control over the data they get (i.e. is it a string, a number, a date or is it not applicable to the current request). A number of people have been using this mod_log_config with my mod_log_mysql without problems for a while now. Configuration for mod_log_mysql looks like this: LogFormat "insert into %{mysqlname}v set host=%h, time=%t, [..]" mysql_format CustomLog mysql:mysqluser!mysqlpassword@mysqlhost/databasename mysql_format That's it, quite straight forward. No extra directives needed, the log format is an SQL command, the %-parameters are handled by mod_log_config (and thus are always the same and still support externals like mod_logio and mod_ssl), the log target looks basically like a familiar URI. This mod_log_config itself implements two log writers, file: and pipe:, which work like mod_log_config always did. The module is 100% backwards compatible, it works both with old external %-parameters (as said, e.g. mod_logio and mod_ssl) and with old external log writers. ----------- In addition to that, this mod_log_config allows to conditionally log accesses not only on environment variables but also on return status codes. This was until now only possible for single items but not for the complete line. Didn't make much sense to me since that might dump a thousand empty lines in my logs if I'm only interested in e.g. bad referrers resulting in a 404. It's better to skip these lines completely and only log if there actually is a 404.
Created attachment 9295 [details] mod_log_config.c, complete file
Created attachment 9296 [details] mod_log_config.h, complete file
Created attachment 9297 [details] mod_logio.c, modified for the new mod_log_config interface (sorry, no patch:)
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.