Hi!

I know the problem... Indeed: http://httpd.apache.org/docs/logs.html#errorlogsays:

" It is not possible to customize the error log by adding or removing information."

For my part, I wrote an error handler module, that processes all errors my application produces. That means I don't warn or die, I call my $err->raise(666, 'devil!'), $err->warn(665, 'almost devil!'), etc. methods, who will put messages in my application logfile (where I can put the request, and additional debugging information alongside the actual error message.), and then die, warn or even take corrective measures. Also, these handlers will print error messages in whatever content type (text/plain, text/html, or text/xml) the client requested automatically.

So the apache log will present only true low level erros (404, 403, server start/stop etc.) and occasionally internal server errors (500), which almost always are what I call production only runtime errors -- bugs that didn't strike during testing, due to smaller load or user interaction not anticipated in test runs... (yep, these things happen to me... ;), or simple syntax errors when testing new code.

In those cases I normally don't need to know the exact request that caused the error -- since the erronous file and line number are logged, I normally find the error by looking at my code... ;)

Any true application level errors are logged in my application's log, where they belong, IMHO.

Spamming the log might help on a low-volume or single child server, but won't do during rapid fire "attacks" by your clients.

I am not an expert in this, but it might be possible to write a mod_perl handler that intercepts error logging.

I also think it's a good wishlist item for the apache project to have a request id/PID in all logfiles, and/or means of customizing the error log format. A combined access/error log would be fine too.