W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: New document on "Simple hit-metering for HTTP"

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 16 Aug 1996 00:04:28 +0200 (MET DST)
Message-Id: <199608152204.AAA05242@wsooti04.win.tue.nl>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul:
>
     [Koen Holtman:]
>    It would be better to [...]
>    instead add stuff to make being cooperative less costly (e.g. a method
>    to piggy-back hit count reports for other URLs on a request you have to
>    send anyway).
>
>I don't think we need to add very much at all for this.  Remember
>that the count report can be sent over the same persistent connection
>as other operations being sent to the server.  A typical count report
>would be
>        HEAD /foo.html HTTP/1.1
>        Host: www.w3.org
>        Cache-control: use-count=37

I guess you are right that this is small enough.  The thing that
worries me more than the size of the request is your requirement on
when to send it: a proxy must send it when removing the cache entry.

But when removing the cache entry, _the proxy does not necessarily
have an open persistent connection to the origin server in question_.
I would be more happy if the draft explicitly allowed a proxy to
report the hit count of a removed cache entry within, say, one day of
removing it.  This would allow the proxy to batch the HEAD requests
for each server and send them at night, when the there is enough
bandwidth left to make opening extra connections not hurt.

Now, from a purely technical `we only specify the cache state
observable from the outside' point of view, you may be able to make a
case that the language in the spec already allows such batching, but
I'd rather see the draft being explicit about this.

I still think that max-uses=N for N>=2 does not work at getting any
kind of reasonable upper bound for uncooperative caches, so that hit
counting can only work accurately if all caches are cooperative.
Therefore, the draft had better make it very easy to be cooperative,
and for some cache implementations it may only be easy if batching is
allowed.

>-Jeff

Koen.
Received on Thursday, 15 August 1996 15:09:31 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:07 EDT