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: Paul Leach <paulle@microsoft.com>
Date: Thu, 15 Aug 1996 18:11:39 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960816011139Z-38776@tide21.microsoft.com>
To: "'mogul@pa.dec.com'" <mogul@pa.dec.com>, "'koen@win.tue.nl'" <koen@win.tue.nl>
Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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 EDT

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