Web Caching

To Intercept or Not To Intercept

Interception caching, a.k.a. connection hijacking, is extremely attractive to proxy and network administrators because it eliminates client configuration headaches. Users no longer need to know how to configure proxies in their browser. Furthermore, it works with all web clients; administrators don’t need specific instructions for Lynx, Internet Explorer, Netscape Navigator, and their different versions. With interception caching, administrators have greater control over the traffic sent to each cache. It becomes very easy to add or remove caches from a cluster or to disable caching altogether.

A related benefit is the sheer number of users using the cache. When users are given a choice to use proxies, most choose not to. With interception caching, however, they have no choice. The larger user base drives up hit ratios and saves more wide-area Internet bandwidth.

The most significant drawback to interception caching is that users lose some control over their web traffic. When problems occur, they can’t fix the problem themselves, assuming they even know how. Another important consequence of connection hijacking is that it affects more than just end users and web browsers. This is clearly evident in the case of Digex and Cybercash.

Certainly, interception caching was in use long before Digex decided to use it on their network. Why, then, did the issue with Cybercash never come up until then? Mostly because Digex was the first to deploy interception ...