- From: Koen Holtman <koen@win.tue.nl>
- Date: Sat, 10 Aug 1996 16:44:42 +0200 (MET DST)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, mogul@pa.dec.com
Jeffrey Mogul: > > This is very interesting... I wrote earlier that we need to > distinguish between two kinds of demographic data: > > 1) Hit counts > > 2) User's Referer field, IP address, User-Agent field, ... > > The proposed hit counting mechanism allows you to get 1) for all user > agents without cache busting, but not 2). You seem to predict that > most advertising sites will want to have 2) in future. That would > make the the proposed hit counting mechanism pretty ineffective at > reducing cache busting. > >This is not true. For any field that appears in the client's >request headers (i.e., not "IP address" but definitely User-Agent), >you can obtain counts without cache-busting (which I would >define as "completely disabling caching"). That is not my definition of cache busting. The cache busting done for demographics reasons will be of the `max-age=0' kind, which allows conditional GETs, rather than the `no-cache' kind. I can't see much difference, as far as efficiency is concerned, between your proposed use of the Vary header and max-age=0 cache busting. Both as are inefficient, but at least max-age=0 is inefficient in a non-complex way. To do a good job at giving demographers the complete request data (including client IP address) they seem to want, a completely different mechanism is needed. Why don't you specify something that lets origin servers tell caches to log certain request characteristics and report them in a future request? The logging overhead for such a mechanism seems to be about the same as for your Vary mechanism. Koen.
Received on Saturday, 10 August 1996 07:47:56 UTC