Origin servers often keep detailed logs for billing purposes. Content providers need to know how often URLs are accessed, advertisers want to know how often their ads are shown, and web authors want to know how popular their content is. Logging works well for tracking these things when clients visit web servers directly.

However, caches stand between clients and servers and prevent many accesses from reaching servers (the very purpose of caches). Because caches handle many HTTP requests and satisfy them without visiting the origin server, the server has no record that a client accessed its content, creating omissions in log files.

Recall that virtually every browser has a cache.

Missing log data makes content providers resort to cache busting for their most important pages. Cache busting refers to a content producer intentionally making certain content uncacheable, so all requests for this content must go to the origin server. This allows the origin server to log the access. Defeating caching might yield better logs, but it slows down requests and increases load on the origin server and network.

Chapter 7 describes how HTTP responses can be marked as uncacheable.

Because proxy caches (and some clients) keep their own logs, if servers could get access to these logs-or at least have a crude way to determine how often their content is served by a proxy cache-cache busting could be avoided. The proposed Hit Metering protocol, an extension to HTTP, suggests a solution to this problem. The Hit Metering protocol requires caches to periodically report cache access statistics to origin servers.

RFC 2227 defines the Hit Metering protocol in detail. This section provides a brief tour of the proposal.

Overview

The Hit Metering protocol defines an extension to HTTP that provides a few basic facilities that caches and servers can implement to share access information and to regulate how many times cached resources can be used.

Hit Metering is, by design, not a complete solution to the problem caches pose for logging access, but it does provide a basic means for obtaining metrics that servers want to track. The Hit Metering protocol has not been widely implemented or deployed (and may never be). That said, a cooperative scheme like Hit Metering holds some promise of providing accurate access statistics while retaining caching performance gains. Hopefully, that will be motivation to implement the Hit Metering protocol instead of marking content uncacheable.

The Meter Header

The Hit Metering extension proposes the addition of a new header, Meter, that caches and servers can use to pass to each other directives about usage and reporting, much like the Cache-Control header allows caching directives to be exchanged.

Table 21-10 defines the various directives and who can pass them in the Meter header.

Table 21-10. Hit Metering directives

Directive Abbreviation Who Description
will-report-and-limit w Cache The cache is capable of reporting usage and obeying any usage limits the server specifies.
wont-report x Cache The cache is able to obey usage limits but won't report usage.
wont-limit y Cache The cache is able to report usage but won't limit usage.
count c Cache The reporting directive, specified as "uses/reuses" integers-for example, ":count=2/4".
max-uses u Server Allows the server to specify the maximum number of times a response can be used by a cache-for example, "max-uses=100".
max-reuses r Server Allows the server to specify the maximum number of times a response can be reused by a cache-for example, "max-reuses=100".
do-report d Server The server requires proxies to send usage reports.
dont-report e Server The server does not want usage reports.
timeout t Server Allows the server to specify a timeout on the metering of a resource. The cache should send a report at or before the specified timeout, plus or minus 1 minute. The timeout is specified in minutes-for example, "timeout=60".
wont-ask n Server The server does not want any metering information.

Hit Metering defines a use as satisfying a request with the response, whereas a reuse is revalidating a client request.

Screenshot 21-1 shows an example of Hit Metering in action. The first part of the transaction is just a normal HTTP transaction between a client and proxy cache, but in the proxy request, note the insertion of the Meter header and the response from the server. Here, the proxy is informing the server that it is capable of doing Hit Metering, and the server in turn is asking the proxy to report its hit counts.

Hit Metering example
Hit Metering example
(Screenshot 21-1.)

The request completes as it normally would, from the client's perspective, and the proxy begins tracking hits to that resource on behalf of the server. Later, the proxy tries to revalidate the resource with the server. The proxy embeds the metered information it has been tracking in the conditional request to the server.

 


Hypertext Transfer Protocol (HTTP)