I have a suggestion for the developers of Apache related to mod_log_config or mod_log_forensics: 1)- To allow mod_log_config to write the log file with a first log entry with basic information about the request before it's processed further (that is, after receiving the headers). The current logging format would be written after the request is processed. A unique "log ID", just like the "forensic ID", should be available on both entries. 2)- Or to allow mod_log_forensic to be configured not to write all headers to disk, or not to write headers at all. I don´t want to miss information about any request. Its important to identify and account for all incoming requests, no matter if they fail or succeed. Since the main purpose here it to account for all the requests and not only trace crash events, the current header information on mod_log_forensicis would not be necessary. This leads to a small log forensics file and less I/O on the server. If I need more information or if i need to trace crash events, then mod_log_forensics would be activated with the all header option.
Option 1 is essentially out of the question... mod_log_config conducts its activity after transmitting the response in part to avoid possible disk contention and delays in servicing the response. Yes, this remains an issue on modern hardware when coupled with servicing 1000's of simultaneous requests. It's also not realistic to spin back the log and change the entry, but mod_log_config is oriented for 1-line per request. So it seems your second option makes the most sense?
Ok, the second option works fine for me. I need to account for all incoming requests and match them to the responses if one is generated. An option without headers allows me to use mod_log_forensics, working with smaller files and less i/o. (In reply to comment #1) > Option 1 is essentially out of the question... > > mod_log_config conducts its activity after transmitting the response in part to > avoid possible disk contention and delays in servicing the response. Yes, this > remains an issue on modern hardware when coupled with servicing 1000's of > simultaneous requests. It's also not realistic to spin back the log and change > the entry, but mod_log_config is oriented for 1-line per request. > > So it seems your second option makes the most sense?
It seems that the access log could also be used to store the completion records, since the unique ID is loggable. Seems like a ForensicOptions might be in order.
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.