draft-ietf-http-logfile-00.txt and multiple directives

In working on converting aws to this format, I've encountered an
interesting problem. To wit:

   The log file format described permits customized logfiles to be
   recorded in a format readable by generic analysis tools. A header
   specifying the data types recorded is written out at the start of
   each log. 


   The directives Version and Fields are required and should preceed
   all entries in the log. The Fields directive specifies the data
   recorded in the fields of each entry. 

Ok - every log file should start with a Fields header. No problem.
However, the model for log files that I'm used to is that
stopping/restarting the server doesn't change the log file in use -
the restarted server starts appending data to the log file.

The problem appears with servers that can change the format of the log
file data. What happens if they format has changed from the old one?
I can see three options:

1) The server closes the old log file and starts a new one. I dislike
	the idea of forcing a log file rename on a user.

2) The server edits the old log file entries to bring them in line
	with the new format. This is expensive at best, and impossible
	at worst.

3) The server spits out a new Fields line, and software that's reading
	it analyzing the log file is expected to deal with it.

I believe #3 is the correct answer.  However, I can't find anything in
the draft mentioning that this these fields can appear anywhere.
Adding such wording seems appropriate. I'd recommend something like:

	Except for the Start-Date and End-Date directives, more than
	occurrence of any directive may appear in the log file. They
	apply to any entries that follow them in the log file until the
	next occurrence of that directive. Analysis tools should be
	able to deal with a new, changed Field directive in the middle
	of the log file.

The exceptions may be wrong; allowing only one start-date & end-date
seems logical for a single log file. Allowing multiple version
directives has implications for backwards compatability that may not
be desirable.

Final note: count and comment claim that they have a type '<>', but
that type isn't defined in the table.


Received on Saturday, 16 March 1996 14:28:48 UTC