So for every piece of data in the proxy, the server will have to maintain
a counter on number of accesses, to be sent when the document expires.
This is about halfway there - *every* client of ours wants stats as to
the busiest time of day for their sites (even to particular parts of
their site) and it doesn't let us analyse "clickstreams" using either
pathway heuristics or RequestID info.[1]
It would be more useful to the server if it gave a more detailed report,
even if it's just a list of RequestID's, timestamps, and Referrers.
UserAgent would be marginally useful as well... perhaps a configurable
format the server could give an an HTTP header on the original attribute?
Yes, this means more bandwidth at the reload time, but it's still less
than all those separate connections.
What would the proxy administrator get out of this? Well, the more info
that can be forwarded, the more likely content providers will start
putting useful Expires in their documents. Web protocols of course
should not be designed around "who's more selfish", but hopefully there's
a common ground that can be reached.
> This proposal requires only minimal changes to caches, servers, and
> log analysis tools -- and offers a graceful, incremental upgrade
> path in the meantime (since Pragma headers are already passed
> through by any conforming proxy). Performance of all components is
> practically unchanged since no additional network connections are
> used. And perhaps most important for successful adoption, this
> scheme avoids imposing any burdensome reporting duties (such as
> "accounting batch runs") on proxy maintainers.
I think this still holds....
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/