more proxy dlf fields (was: Re: PROPOSAL: schema for proxy superservice)

[Francis J. Lacoste]

Most of the fields can be mapped to existing field in the
proposal. (I did consult the ISA log specification when coming
up with the schema.)

On Fri, Jan 18, 2002 at 01:26:31AM +0100, Joost van Baal wrote:
[...]
> 
> I've found
> 
>     'c-agent'        => 'ms_agent',
>     # e.g. Mozilla/4.0 (compatible; MSIE 5.0; Win32)

This is one isn't in the schema. I didn't include it because I'm not
sure it is interesting in a proxy report, but I may be mistaken. We
could add it as

user_agent => string (for compatibility with the www superservice).

>     # or Outlook Express/5.0 (MSIE 5.0; Windows 98; DigExt)
>     
>     'cs-protocol'    => 'protocol',

This one is already mapped.

>     
>     'cs-referred'    => 'referred_host',
>     # Referring server name (cs-referred): If ISA Server is used upstream in
>     # a chained configuration, this indicates the server name of the
>     # downstream server that sent the request.

I'm not sure I understand this field. At first I thought it was the same
as the result_src_ip/result_src_host (which contains the server which
returned the requested object, either the source server or the next
cache in a cache hierarchy.

But from the comment, I understand that it can contain the downstream
server in a cache hierarchy. (Where in squid's log that would be
contained in the client_ip field: squid's logs, don't contains the
original client_ip, only the ip of the client that made the request which
may be the original client or downstream cache).

We could add a cache_client_ip/cache_client_host which could be used
for this case.

>     
>     'r-host'         => 'dst_host',
>     'r-ip'           => 'dst_ip',

Those already exists.

> 
>     'r-port'         => 'dst_port',

I thought port information wasn't really important in that case. So I
dropped the information.

> 
>     's-computername' => 'computername',
>     # Proxy name (s-computername) The name of the computer running ISA Server.
>     # This is the computer name that is assigned in Windows 2000. e.g. GRO1SYX01

This is like the hostname field in syslog. I'm not sure it is pertinent
to have that field in the DLF schema. I think this information would be
more pertinent once we define a way to handle generically
multiple-server logs (like in a centralized syslog setup).

> 
>     's-object-source'=> 'object_source',
>     # Object source (s-object-source) Indicates the source that was used to·
>     # retrieve the current object. This field applies only to the Web Proxy·
>     # service log.·
>     #
>     # values and their meanings:
>     # 0           No source information is available.
>     # Cache       Source is the cache. Object returned from cache.
>     # Inet        Source is the Internet. Object added to cache.
>     # Member      Returned from another array member.
>     # NotModified Source is the cache. Client performed an If-Modified-Since
>     #              request and object had not been modified.
>     # NVCache     Source is the cache. Object could not be verified to source.
>     # Upstream    Object returned from an upstream proxy cache.
>     # Vcache      Source is the cache. Object was verified to source and had
>     #              not been modified.·
>     # VFInet      Source is the Internet. Cached object was verified to source
>     #              and had been modified.

That's the equivalent to the result_src_code field. It has different
code than squid but it contains the same information (where the object
was fetched).

> 
>     's-operation'    => 'operation',
> 

That one is mapped.

> in a MS ISA server log.  How about adding these to the proxy dlf
> specification?  Or do you feel an extended scheme could better be used
> for these?  I have no clue about this yet...
> 

Basically, we have three more fields

user_agent 
cache_client_ip
cachce_client_host

Two fields I'm not sure that they are pertinent:

port
computername


-- 
Francis J. Lacoste
francis at Contre.COM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20020118/3a857d04/attachment.bin