Ads in Cache-Friendly Pages
Pages: 1, 2

A cache-friendly way of serving ads

One way to make ads extremely cache-friendly and still be able to count the hits is to use cacheable images, but use "302: Found" or "307: Temporary Redirect" to reach the ad. The browser makes a GET request to the server, is redirected, and makes an additional GET request for the ad, which is served from the proxy. The server can count the redirects to count the hits on the ads.

307: Temporary Redirect is an entity header that requests the browser to send another GET request for the actual entity, but to ask for the original entity next time (unlike "301: Moved Permanently"). The URI to redirect to should be given by the Location field in the response and also in the content of the 307.

302: Found is also a suitable entity header for this purpose, but it's ambiguously managed in many browsers. A comment in RFC 2616 explains why it was split into "303: See Other" and "307: Temporary Redirect."

The advantage of this method is that the images themselves are cached, but you can still count the hits on the ad--and most caches do not cache redirects, so your hit-count is more accurate than for ads without Cache-control headers. The specification explicitly states that 307 is not cacheable unless stated otherwise.

You and your customers save bandwidth on the images, and your hit-count is as accurate as for images with No-cache headers. Everyone wins!

There is a latency cost, as the browser sends the GET request for the image, receives the redirect, and sends another GET request for the actual image. In most cases, this will be slight, especially if the browser is behind a cache that already contains the ad image.

If the image is cached, total bandwidth is reduced. If the image is not cached, total bandwidth is increased by the size of the second GET request and the 307--both extremely small.

Apache implementation

In the page that contains the ad, use an image tag that displays the correct height and width for the banner. The image tag should point to a URI that doesn't actually exist, but that is used to handle the redirect.

The redirect is managed by the mod_alias directive Redirect. Ensure that httpd.conf is set to load mod_alias. You may need to recompile Apache after editing this file.

#
# Dynamic Shared Object (DSO) Support
#

LoadModule expires_module /usr/lib/apache/1.3/mod_alias.so

The Redirect directive may be set in any of the document realms. See Cache-Friendly Web Pages for a description of Apache document realms and how to set directives within realms.

For our purpose, either a 307 or a 302 (temp) redirect will serve. Set the source to the fake URL the page refers to, and the second to the advertisement you actually want to display. The first path must be an absolute path from the current host. The second must be a full URL.

Redirect 307 /path/in/page http://host.and/path/to/advertisement

or

Redirect temp /path/in/page http://host.and/path/to/advertisement

The redirections will be logged in the access log. From there, count hits for each advertisement with a log-analysis script.

Perl implementation

If serving banners via a CGI script, you can write the redirection into the script. Return the Status and Location headers rather than returning the actual image.

In the page, include the image as a link to the CGI script, something like <img src="http://mybannerserver/banner.cgi">. This will call banner.cgi, which issues a redirect to the image that the browser then calls. You can then read your ad hits from your access logs, or record them as part of the script.

A sample banner.cgi, stripped to the barest minimum, is:

#!/usr/bin/env perl

	sub Pick_a_banner()
	{
		# Use whatever algorithm you prefer 
		# to choose the banner URI
		return "http://myserver/defaultbanner.gif"
	}

	$banner_uri=Pick_a_banner();
	print "Status: 307\n";
	print "Location: $banner_uri\n";
	print "\n";
	exit 0

Caveats and gotchas

If your advertisements are served from a Web server you have no access to, you may not be able to make the ads themselves cache-friendly. But you can still make your pages cache-friendly without affecting the ads.

Final words

This is just one method of making ads cache-friendly. The explanation of entities and the examples should let you modify your own system to be as cache-friendly as possible.

Further reading

• RFC 2616
• Your Web server documentation
• HTML specification
• Cache-Friendly Web Pages

Jennifer Vesperman is the author of Essential CVS. She writes for the O'Reilly Network, the Linux Documentation Project, and occasionally Linux.Com.

---

Return to the Linux DevCenter.