Implementing Vary in Squid-2.4

This implementation will only include "basic" support for Vary. Full support for ETag is not in the scope of the implementation at this time, but is planned for later.

Store changes

As the Squid object store structure is not yet designed to handle multiple entities for one URL, the implementation has to build a additional layer on top of the store to do this. For this, A new kind of special "vary" store object is introduced to keep information about the variance. This "vary" object includes

• The fact that the resource varies
• What request headers the variance is based on (i.e. the Vary header settings).
• How to use this information to build the store object name for each request identity (request identity == combination of Vary marked headers).

This marker object is created automatically on demand when a varying object enters the cache.

Cache hit flow

When a store special "vary" object like the above is found on a cache hit, the store is then re-queried, including the relevant request headers as specified in the "vary" object.

This is done by updating the HttpRequest structure with information that the underlying object varies and on what, and then restart the cache lookup.

Cache miss flow

When reply headers indicates that the object varies, first a "vary" object is written containing this information. Then the cache key of the retreived object is changed to include the headers marked with Vary.

When a cache key is set including Vary information, the store automatically creates the "vary" marker object.

Where in the code

Changes needs to be done at three locations

1. Client side, to manage cache hits on "vary" objects, similar to how If-Modified-Since hits are managed. When the object meta data has been swapped in the vary information is evaluated, and the lookup process perhaps restarted with vary information included.
2. Client side, to handle variance in PURGE
3. HTTP protocol side, to catch the Vary header, and optionally (if it doesn't exists already)
4. Store functions, to create/update the vary "marker" object when needed.
5. Store metadata functions, to add the vary information to the object metadata
6. Store client, verifying that the vary information for a HIT is correct (corner case, for the highly unlikely event that two different variants of the same object gets the same cache key)
7. Store key generation, to include the Vary marked headers in the store key

Limitations

• If the type of variance changes (list of headers included in Vary) then any previously cached entities will be "forgotten", as the key to those objects have now changed.
• Does not support "fuzzy" matches. Even such a change as a minor browser version difference (if "User-agent" is included in the Vary list) will cause a cache miss.
• Not that easy to purge objects from the cache. The PURGE operation must include the exact request headers of matching the reply that one like to remove from the cache.