Hit Metering

21.3 Hit Metering

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

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

[13] 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 logsor at least have a crude way to determine how often their content is served by a proxy cachecache 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.

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

21.3.2 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" integersfor example, ":count=2/4". [14]

max-uses

u

Server

Allows the server to specify the maximum number of times a response can be used by a cachefor 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 cachefor 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 minutesfor example, "timeout=60".

wont-ask

n

Server

The server does not want any metering information.

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

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

Figure 21-1. Hit Metering example

figs/http_2101.gif

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.

 



HTTP. The Definitive Guide
HTTP: The Definitive Guide
ISBN: 1565925092
EAN: 2147483647
Year: 2001
Pages: 294

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net