httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@organic.com>
Subject RE: hit-metering (fwd)
Date Tue, 26 Mar 1996 00:39:22 GMT

For the proxy folks.  Does this rub any of you the wrong way?  It would 
certainly be enough for me to encourage our clients to make more of our 
content cacheable.  Even though I won't get goodies like cookie numbers, 
I'll use statistics to extrapolate now that we know how undercounted we 
are...

	Brian


---------- Forwarded message ----------
Date: Mon, 25 Mar 1996 16:03:46 -0800
From: Paul Leach <paulle@microsoft.com>
To: 'Brian Behlendorf' <brian@organic.com>
Cc: "'hallam@w3.org'" <hallam@w3.org>
Subject: RE: hit-metering 

The idea was to do something really simple in the 1.1 timeframe, to
convince as many content providers as possible to not disable caching in
order to collect simple demographic information, so there is some
urgency. Phill and I agree that the "pull" model described in Phill's
recent I-Ds is the right way to go in the medium/long run, but I think I
convinced him that something simpler was appropriate for the near term
as long as it was consistent with the longer term direction.

Here's the original proposal, updated with the results of Phill's
comments:
---

At the caching subgoup meeting, there was concensus that some really
simple form of hit metering would go a long way to meeting content
provider demand for demographic information, and that only something
really simple could be available in the 1.1 timeframe.  We discussed
what it might look like a little bit, and there was a volunteer to write
up a proposal, which they said they was very similar to one that they
had/were implementing.  That person never delivered.

It's pretty important to us (MS) that there be something along that
line, so I've taken the bull by the horns and written something up. 
Larry thought that if the three of us came to closure on something, it
could be "fast tracked" either into the main 1.1 spec, or as one of the
family of 1.1 spec documents, or as a separate doc in the 1.1 timeframe
-- to me it doesn't much matter.

Here's exact text, either for inclusion in 1.1 or as the main part of
another I-D:
==========================
10.xx Cache-Info

The Cache-Info request header field can be used by caching proxies to
indicate to origin-servers how many times a request for the resource
indicated by the Request-URI in the request-message containing this
field has been satisfied from the cache, and in the future can be
extended to provide other information to the origin-server that the
cache has discovered.

Cache-Info

     Cache-Info   = "Cache-Info" ":" cache-name 1*(; cache-option)

     cache-name      = dns-name		; name of the proxy-cache
     cache-option    = hit-count | extension-parameter

     hit-count       = "hit-count" "=" *DIGIT

The value of the field in a request for a particular resource is the
number of times the proxy has satisfied a GET request for the resource
from the cache since the last time it included Cache-Info in a request
to the origin-server for that resource.

Cache-Info can be optionally included in any request, but conditional
GETs to re-validate cached resources provide an opportune time to
include this information without significant extra cost. It may also be
included with HEAD requests just before flushing a resource from a
cache, although this incurs significantly more overhead than just
piggy-backing on a GET that needed to be done anyway.

There are policy issues with the use of Cache-Info that are outside the
scope of the HTTP protocol. Examples are: Should the proxy send a final
hitcount via HEAD? This could be a contractural issue between proxy
servers and content providers: the content provider will omit "no-cache"
directives in reponses to particular caches in exchange for hitcount
reporting. Which downstream clients should a proxy trust to report
hitcounts? A proxy may choose to only forward hitcounts from downstream
proxies to its own when it can authenticate them using
ProxyAuthentication, for example.
================================

I realize taht there may be many needs that this won't meet, but the
caching group felt that something like this would be enough to convince
many content providers to enable caching, which they previously disabled
just to get hit-count information.

Your comments would be greatly appreciated.

Paul
>


Mime
View raw message