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

Sure -- it already says it need not wait for the HEAD request to finish
before removing the item; it wouldn't hurt to mention that it can defer
(and batch) the requests as long as there is a high probability that it
will get made.

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Sent: 	Thursday, August 15, 1996 3:04 PM
>To: 	mogul@pa.dec.com
>Cc: 	koen@win.tue.nl; http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Re: New document on "Simple hit-metering for HTTP"
>
>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 18:15:08 UTC