Logging Trivia

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.
389c7753 389c7753100007f47061b10 127.0.0.1 /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 log entries, of whatever type, that are generated by that client. 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.

The following remaining fields are the IP address of the remote client, the file they received, the total bytes sent during the transfer, and how many seconds the transfer took to complete. Note that this last field isn't entirely accurate as it is recorded when the last bytes enter the outgoing TCP buffers on the connection, not when the bytes actually leave the machine.

Entries generated by a thread to a single file will be written in chronological order. If, however, multiple threads or sources are sharing an output file, the resulting entries may not be written in chronological order. It is up to parsing programs to use the 'time' field to sort by if they care about chronological order.

The parsing order of the logging section is unfortunately an issue. The global logging section will be parsed before any other section of the config file. This ensures that templates defined in the logging section will be available for later virtual sections. However, the parser only makes a single parse over all the route entities. This means that you must be careful about when you define a tag and when you reference it. This will be fixed by doing a second evaluation pass after all the definitions are made.