a home for squid2dlf

[Francis J. Lacoste]

I think we should probably define a new proxy superservice.

But let me first say that it could be appropriate to have a converter
from squid to www DLF. But this would be only pertinent for case where
squid is use as a HTTP accelerator. (That is a cache in front of a web
server) In that case the information you are interested from squid is
the same as the webs server.

But I think that the questions you are interested in when used as a
proxy is really different from when the www service.

Besides all the performance issues about cache hits, renewal, etc that
are specific to a caching service, even the questions relating to access
(that superficially appears similar to the www superservice) are
different.

For example in a proxy superservice. I would be less interested by the
files that the users access, then by the site they go to. Informations 
that isn't really available from the www superservice. Remember that the
URL in a proxy service will be an absolute URL and not a relative one
like the ones in the www superservice.

I think all this make the creation of a new superservice very pertinent.

On Wed, Nov 14, 2001 at 03:19:40PM +0100, Joost van Baal wrote:
> Hi,
> 
> I started hacking on squid2dlf, as contributed by Joost Bekkers.  I am
> wondering wether it would be sane to (keep) this under the www
> superservice.  squid logs stuff like:
> 
>   979992041.366 502 192.168.1.160 TCP_IMS_HIT/304 216 GET
>          http://example.com/home2.html - NONE/- text/html
> 
> This has some similarity with www.xml; it might be wise to use the
> extension mechanism.  However, the difference might be too big.  We miss
> "referer", "useragent", "gzip_result" and  "compression".  We'd have to
> add "elapsed", "cache_result_code", "servername" and "ident".  (See the
> just commited squid2dlf manpage for description of these fields.)
> 
> I find it hard to make a sane guess at what would be the best choice:
> keep with www, or define a new superservice like e.g. "proxy".
> 



-- 
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/20011116/6dc93111/attachment.bin