On Fri, 15 Oct 2004, Luc Pardon wrote: > I patched mod_log_config.c (from the 2.0.51 distro) to allow > conditional logging on HTTP status code, like so: > > CustomLog king-size.log common status=414 > > The patch also supports "not" and lists (like the %.. syntax) and > "wildcards", e.g.: > > CustomLog ungood.log common status=!20x,3xx > > The changes are non-intrusive and the patch is of course backward > compatible.
Sounds somewhat interesting, and (as you note) there's quite a lot of demand from people who don't like 414 crap in their logs. So that's a good start. But how does it work with piped log programs? If I were implementing this functionality, I'd probably hack rotatelogs rather than httpd. > I already patched the docs and am willing to go the extra mile(s) to > make it all "nice", but the "guidelines for contributing a patch" say > you're a conservative lot when it comes to new functionality. Indeed, that's true. But that's very minor functionality and clearly tied in to an established core module, so unlikely to fall down on that. The usual fate of patches in bugzilla is that, even if they are appropriate for inclusion, they need a committer to take sufficient interest to review and incorporate them. A chronic shortage of round tuits means this is rather hit-and-miss. > One more thing: I became aware that the "flexible interface for > mod_log_config" patch (# 25014) also allows conditioning on status > code(s), and there are three other contributed patches against > mod_log_config waiting for a decision (# 28037, 29449 and 31311). I am > willing to ensure compatibility with any or all of them if desired. If you can fix a whole bunch of related bugs on bugzilla without your patch becoming big and complex, that adds value but still doesn't guarantee anything. Ask yourself: is your code sufficiently different to anything we already have to merit releasing separately as a third-party module? If yes, then do that. If no, then it's probably appropriate to offer a patch. My guess would be no. -- Nick Kew
