[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-bugdb
Subject:    general/7163: wishing for better logging primatives
From:       Kurt Lidl <lidl () pix ! net>
Date:       2001-01-31 5:13:08
[Download RAW message or body]


>Number:         7163
>Category:       general
>Synopsis:       wishing for better logging primatives
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Tue Jan 30 21:20:02 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     lidl@pix.net
>Release:        all
>Organization:
apache
>Environment:
all -- this is a request for enhancement, not a bug per-se
>Description:
For a long, long time (since before there was an apache!) the company
where I used to work (UUNET) has run a customized version of the webserver
du jour (used to be NCSA, now is apache) which logged more information
than what you can get out of the LogFormat primatives.

Basically, there are three things that cannot be specified in the LogFormat
specifications that would be useful to have.

1) A cheap way of specifying the time a request was received as a unix time_t
 value in the log file.  While this can be (almost) accomplished via the
 %...{format}t directive, I just want the totally unambigious unix time_t
 value.  This should be trivial to implement.

2) A varient of the %...T format that gives the time it takes to service a
 request in fractional seconds, hopefully with a user-specified degree of
 precision.  This is useful in diagnosing performance problems.  When rounded
 to seconds, almost all of the values on my current server are zero, which
 isn't really very useful.

3) A standard, robost escaping mechanism that can be applied to the
 ident/username field, the user-agent and the requested URL fields.
 Obviously, having a single mechanism would allow for code reuse.
>How-To-Repeat:
Read the documentation, notice that the directives don't exist.
>Fix:
While not a suggestion for the code, I am appending the relevant man-page
section that has been in use for ages.  It more fully explains the rational
behind the desire for this log format.

The new output format contains the following fields:

     remote IP address
     status
     bytes sent
     start time of transaction (a time_t)
     duration of transaction in seconds
     user name given for password authentication
     request type and URL
     referer
     user agent

     The last four fields (the string values) are enclosed in double quotes.
     If double quotes or backslashes appear in the values, they are preceded
     by a backslash.  Newlines in the values are represented as backslash-n.

     This new log file format is easier to parse than the NCSA format, which
     has the deficiencies that parsing the time format is complicated, some
     fields (such as the user name) can contain spaces but are not quoted, and
     some quoted fields (such as the URL) can contain quotes that are not es-
     caped, so it is hard to know where the fields begin and end.  Also, the
     NCSA 1.3 httpd does not log the referer and user agent fields.  The 1.4
     version does, but in separate files that can not be correlated with the
     rest of the log information.

Thanks for listening!
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]
 
 

[prev in list] [next in list] [prev in thread] [next in thread]