Server vendors are getting quite a lot of customer pressure to provide hit-counts that include what happens at caches. In the absence of a mechanism to do this, some servers are disabling caching simply to obtain hit counts, and we agreed that this is not good.

Most (but not all) of us agreed that it would not be possible to make hit-metering mandatory for caches, simply because there is no obvious way to enforce an anti-cheating policy.

Customers have asked for several kinds of hit-metering, with increasing levels of complexity and cost:

  1. simple hit counts: the cache tells the server how many hits have been made on a particular cached value.
  2. access-log transfers: the cache sends to the server complete access logs (in some standardized format) so that the server can tell which clients have made what requests and when.
  3. client navigation traces: the cache sends to the server enough information to determine how the user got from one page to another.
It's not entirely clear whether (3) is really different from (2), or whether the access logs contain enough information to satisfy the people who want (3). None of us were thrilled about either (2) or (3), but there seems to be some customer pressure and so we felt obligated to consider it.

Netscape has internal specifications for (1) and (2?), and will write them up and circulate them to the subgroup.

ACTION ITEM: Ari Luotonen and Chuck Neerdaels will provide a proposed specification for hit-counting (and perhaps for access-log transfers).

Jim Gettys has some contacts with the demographics people who were keen on wringing more access-measurement information out of the web, and will find out more specifically what they think they want.

ACTION ITEM: Jim Gettys will grill the demographers.

Is this what prompted the Hallam-Baker draft on log file format?


http working group issues