Summary

  • In 1996 Duane Wessels forked the last pre-commercial Harvest Cache Daemon code, renamed the independent branch Squid, and released version 1.0.0 in July.
  • Early Squid changes show continuity through maintenance: support for conditional HTTP requests, HTTPS objects, and rebuilding the disk cache while requests continued.

A research project can close while one of its tools is still answering requests. That was the practical question around Harvest’s Web cache in 1996. Harvest had developed several components, including the object cache, but people on the project moved into industry as a separate, NSF-funded caching study got under way. Duane Wessels, who had worked on Harvest, needed public code for that deployment and research work. His later technical account says he started from the last pre-commercial Harvest version, enhanced it, and named the branch Squid to distinguish it from another commercial derivation.

That was a fork with a specific operating purpose. The cache sat between users and distant Web servers, keeping copies of popular objects so repeat requests could be served closer to the user. Harvest’s design also supported cache hierarchies. The need was visible beyond the laboratory: a 1996 account of New Zealand deployments reports that Harvest Cache had entered production use in October 1995. By February, one server was handling traffic equivalent to about five per cent of the country’s Internet traffic with the rest of the world. That figure describes one operator’s estimate in one geography; it is not a measure of global adoption.

The first Squid release was not just a new label on an untouched archive. The project’s 1.0 beta change log, dated 19 April 1996, identifies its base as Harvest cached-1.4.pl3 and lists added support for If-Modified-Since requests, SSL objects, and background disk-store rebuilding while the cache continued to serve requests. These changes addressed the work of running a proxy: validate whether a stored object had changed, handle a wider kind of connection, and perform maintenance without making the service wait. The official 1.0.0 release followed in July.

Wessels’ later account describes a stream of code contributions, patches, requests and error reports during the following year. The changelog provides a closer view of that process: small fixes appeared in successive releases, while Squid retained compatibility work for Harvest-cache neighbours. In 1997, RFC 2186 documented ICP, a quick query-and-reply protocol for neighbouring caches; it traces the protocol’s roots to hierarchical caching in Harvest. A fork could change the software while leaving shared operating arrangements legible to other caches.

Squid’s origin therefore shows a particular kind of continuity. The Harvest project’s name did not have to survive intact for operators to keep running a cache. A maintainer could take a known code base, publish a distinct branch, and make changes against observed requirements. That did not guarantee permanent support: the new project still needed people, funding, and compatible deployments. It did turn a research output into software that could be revised on a release schedule.

Sources