Bug 49926 - New option for mod_log_forensics or mod_log_config
Summary: New option for mod_log_forensics or mod_log_config
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_log_forensic (show other bugs)
Version: 2.2-HEAD
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2010-09-14 08:26 UTC by Sergio Junqueira
Modified: 2018-11-07 21:08 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio Junqueira 2010-09-14 08:26:02 UTC
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.
Comment 1 William A. Rowe Jr. 2010-09-14 08:38:09 UTC
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?
Comment 2 Sergio Junqueira 2010-09-14 13:22:11 UTC
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?
Comment 3 William A. Rowe Jr. 2010-09-14 14:08:11 UTC
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.
Comment 4 William A. Rowe Jr. 2018-11-07 21:08:45 UTC
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.