W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Comments on draft-mogul-http-hit-metering-00.txt

From: Koen Holtman <koen@win.tue.nl>
Date: Sun, 23 Feb 1997 21:04:41 +0100 (MET)
Message-Id: <199702232004.VAA00690@wsooti08.win.tue.nl>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2537
Jeffrey Mogul:
>This is because I don't think it's appropriate to characterize this
>use of "Cache-control: proxy-maxage=0" as "frivolous", especially
>when used with usage-limiting.

I would characterize the new "proxy-maxage=0" as less frivolous than the old
"proxy-revalidate": the new one does not have any `mission critical'
annotations with it in the 1.1 spec.  I think leaving the Meter header out
while adding only `proxy-magage=0' is fine, so this problem seems to have
solved itself.

>    HTTP/1.1 does not define conditional HEADs, you will have to define
>    them yourself.
>It doesn't specifically define "conditional HEADs", but it does
>describe "conditional methods" in section 13.3:
>(We seem to have overlooked the description of If-Modified-Since,

The IMS description is probably what led me to the wrong conclusion.  OK.

>    In an earlier message, I outlined a cheap `BogoHits' system which
>    would get you good _click_ counts, where a one click was defined as
>    one mouse click on a page link by an actual end user.
>It would be nice to have a fully specified proposal to review,
>as an Internet-Draft.

I think I'll do us both a favour and not write such a draft.  Demographics
is not that high on my priority list. (I'm commenting on hit metering because
of its possible impact on web traffic: optimizing web traffic _is_ high on
my list.)

>    Section 4.2:
>    >Why max-uses is not a Cache-control directive
>    I think your reasoning is flawed here: the Meter header can be used to
>    negotiate on the honoring of max-uses no matter whether max-uses
>    appears in the Cache-Control response header or in the Meter response
>    header.
>I'm not sure I would call the reasoning "flawed"; maybe it could
>be called "leaving a few steps for the reader".  We could have
>written the entire proposal to invent a new kind of hop-by-hop
>Cache-control directive, to be carried in the existing
>Cache-control header, but then this would be a modification to the
>HTTP/1.1 spec.  Right now, the HTTP/1.1 spec says (14.9):
>   Cache directives must be passed through by a proxy or gateway
>   application, regardless of their significance to that application,
>   since the directives may be applicable to all recipients along the
>   request/response chain. It is not possible to specify a cache-
>   directive for a specific cache.

I don't think that last sentence forbids you from doing subnegotiation on a
cache directive to make it apply to a single cache.  But maybe the point is

>    Section 5.3.1:
>    I believe your system will always count a page _pre_fetch done by a
>    proxy as a hit, no matter whether the page is actually seen by a user
>    later.  You need to fix this.
>The hit-metering proposal might need to be
>fixed, but the general problem is broader.

I am aware that there is a broad problem, but you need to fix this
sub-problem nevertheless.  Just define some flag that the cache can include
if it does a prefetch.  I'm aware that this does not solve the problem of
prefetching outside of the metering subtree.

>    Even if cache busting turns out to be done mainly to get hit counts,
>    one could still make a case against your proposal.  If we don't
>    optimize unwanted origin server behavior, the unwanted behavior will
>    disappear by itself eventually, because users will vote with their
>    mouse-button and move on to faster sites.
>Wishful thinking, I believe.  Users judge servers on their overall
>utility, not just on the network-level aspects that we geeks are
>so concerned with.

Presumably, cache busting makes things slower.  So the users will see a slow
server, and they know how to judge slowness, even if they are not aware of
the network-level reasons for it.


Received on Sunday, 23 February 1997 12:11:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC