Re: http://www.w3.org/pub/WWW/TR/WD-logfile.html

> >Firstly, I think there should be another identifier for authentication name
> >(like what is present in the CLFF).  (I'm suprised there haven't been more
> >request along this line, other than the geographic business being talked
> >about earlier, no one has requested additional identifiers?)
> The problem here being how to define the manner in which the name is obtained.
> Some people are using cookies to abtain authentication names...

I noticed that was missing as well. Yes, you want hooks to log where
the data came from, even without the cookies stuff. For instance, I'd
be interested in Digest vs. Basic authentication.

I figured this that authentication would be part of the
application-specific information. Especially since I have a facility
for annotating a request (a natural for application logging) which is
used to pass authentication information around. I'd name it something
like "x-notation-remote_user" and "x-notation-auth_type".

> It is an oversight though..
> [1010] Representation of User name
>     Not bright to log BASIC auth strings for this purpose

Along the same lines, what about identd names? It is possible to get
both of them.

> >I didn't see it addressed what's suppossed to occur with multiple headers,
> >like cs(Accept).  Is comma folding a requirement?
> Yes, I would have thought implicitly in the HTTP spec??

That's what I thought as well. Maybe an explicit reference to the HTTP
spec?

> >And I didn't see it addressed if there should be, or if there can be, any
> >hard limits on headers sizes, and how it would be indicated if the log-file
> >generator (the server) decided it wanted to cut off the logging of a
> >Foo-Bar: header after one K.  Is that acceptable practice?
> Good plan! How to do it though? Perhaps we could have a - trailing the close
> quote "http://fooooooooobaaaaaar.com/vvvvvvvvvvveerrylllllonggggg"-  ?? Or is
> that liable to be awkward for parsers? How about "!" or ~ ? Feelings anyone?

How about informing the parser of the limit in the #Fields header? If
it only applies to string-valued objects (right?), then something like
"cs(accept, 5120)" would do, with a missing number meaning it's not
limited. If this needs to be applied to other types, then prepending a
limit like "s-dns<5" would do the trick.

I don't see any reason the parser should have to deal with an entry
having been truncated. The analyzer may not care that it's been
truncated. If it does care; knowing the truncation length allows that
information to be derived.

> [1019] Reword to make it clear that placing the end data at the head of the log
> is an option not an obligation.

I assume you mean "end date", not "end data". Since Version and Fields
are required, I'd say that the others are clearly optional at the head
of the log. There's no other wording to indicate that there is a
required placement for anything, or for that matter to indicate that
those two are not allowed elsewhere in the log file. We even talked
about putting Fields elsewhere in the log file to indicate that the
user has changed the log file configuration in the middle of a log
file.

I can't seem to find a link to the issues list to check on whether
that made it to the list.

	<mike

Received on Wednesday, 27 March 1996 12:27:05 UTC