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

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,
>however.)

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
debatable.

[...]
>    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.

[...]
>-Jeff

Koen.

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