phhttpd maintains log buffers for each log it writes to. Logged events are put in
these buffers at reporting time rather than being immediately written to disk. These
logs are written as they are filled during normal operation, or at regular intervals.
This greatly reduces the performance impact of keeping detailed logs.
phhttpd keeps interesting logs on a virtual server granularity.
You can specify which logs you wish to keep by including an entity
in the log section of a virtual server for each source you wish to log.
There is an entity for each source of logging, and attributes to that
entity define where it is logged.
It looks something like this:
<LOGSOURCE mode=OCTALMODE file=PATH>
mode is the octal permissions mode of the file that is
to be opened. As it is parsed by dumb routines, a leading 0 is highly recommended.
file is the file to which the logged events will be written.
The LOG_SOURCE is one of:
|access||Successfully answered requests|
The value given in the 'User-Agent' HTTP request header|
The string given in the 'Referer' HTTP request header|
phhttpd log entries are contained with a single line in a text file. They contain
the time the log entry was written, an opaque token that is associated with the connection
that caused the log entry, followed by the actual entry.
The contents of the 'referer' and 'agent' log entries is simply the string
that was given with the header. The contents of the 'access' log is a little more
interesting. It has the decoded relative URL that was asked for, followed by the total bytes
that were transfered, and the time in seconds that it took to transfer.
387f7a45 387f7a45800210ac8910500 /index.html - 2132 0
is an entry from an 'access' log.
The first field is the time in seconds since the Unix epoch, a.k.a. time_t. The second field is associated with the client connection that caused the log
entry. It is constant for the duration of the connection, and is written to all the logs
entries, of whatever type, that are generated. This allows a log parser to do more complete
connection granularity analysis. As it happens, this opaque token is currently built up
of the time the client was connected, its remote and local network address, etc, but these
values most _not_ be parsed as they may change in the future.
Entries generated by a thread will be written in chronological order. If, however,
multiple threads are sharing an output file the resulting entries may not be written
in chronological order. It is up to the parsing programs to use the 'time' field
to sort by, if they care about chronological order.