Cache peerings and the Vary HTTP header

Implications of the Vary HTTP header on cache peerings

The ICP and cache-digests protocols are somewhat limited when it comes to varying objects. Both of these protocols does not include enough of information to indicate how a given URI varies

ICP peerings

ICP only carries information about the URI, which leaves two options:

1. Answer positively if there is any variant in the cache, hoping that the request is for one of the ones fresh in out cache.
2. Negative answer

Cache digest peerings

Cache digests allows for some information about the variance. If the two caches agrees on how to encode the cache key for variants, then the peer can check if there is a variant in the cache by looking up the cache key in the digest.

However, digest cannot convey the information on how the obejcts vary (i.e. the Vary header itself), and this information must be known to the peer in order to be able to construct the cache key. This leaves two options:

1. The base URI is included in the digest if any cached variants exists, and hope that the first request is for a variant in the cache. False hit recovery will deal with the cases where it is not, at the expence of one HTTP message RTT (request + denial response).
2. The base URI is not included, requiring the peer to first find out how the object varies on it's own before any variants can be found in the digest.

For the first case (base URI included) the false-hit message could optionally include the information that the object varies, but it is at this time unclear if doing so would bring any benefit to the peering relation. In the end the peer has to find a source for the object anyway, and there the vary information should also be available.