Code change:
2.1.3. <del> The "ttl" value of the Use-As-Dictionary header is a sf-integer value that provides the time in seconds that the dictionary is valid for (time to live). The "ttl" is independent of the cache lifetime of the resource being used for the dictionary.  If the underlying resource is evicted from cache then it is also removed but this allows for setting an explicit time to live for use as a dictionary independent of the underlying resource in cache.  Expired resources can still be useful as dictionaries while they are in cache and can be used for fetching updates of the expired resource.  It can also be useful to artificially limit the life of a dictionary in cases where the dictionary is updated frequently which can help limit the number of possible incoming dictionary variations. The "ttl" value is optional and defaults to 1209600 (14 days). 2.1.4. </del> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present then it MUST be sent to the server in a "Dictionary-

Related discussion:
text: If not, it will compress resource A in a different way the client supports. (Of course, this doesn't prevent the CDN from having some amount of second-layer caching to avoid recompressing frequent combinations.) Personally, I tend to think the second tends to have better properties -- you don't have an explosion of cache entries or origin requests for the long tail, you simply fall back to a non-dictionary compression scheme. CDNs might choose to count usage as a dictionary as a cache hit for Z, making it stay in cache as long as it continues to be used by clients, but might not choose to fetch Z again if it ages out of the cache. (The interesting quirk from a CDN perspective is that a single resource might have multiple old versions still getting "hits.") The two then probably imply different ways of thinking about lifetimes. In the first case, you could want a separate lifetime on the dictionary to feed into how long the CDN needs to keep around the f(A,Z) item. In the second, the lifetimes of the individual objects likely suffice. (For that matter, if the client is identifying the version of Z it has, then it doesn't really matter whether that object is fresh or not, only whether the server still possesses the indicated version.)
The main use case for this is for something like a web app at build time where they pre-compress the resources at build time for some number of previous releases. At serving time, the CDN doesn't have any special dictionary logic and just honors the headers to vary on and the origin checks for pre-compressed assets using the requested dictionary (in my apps that I was doing this with, I just added the hash to the end of the file name and did a quick file check). On a miss, the origin sends the full resource which ends up in a separate cache key on the CDN. This allows for origins to support dictionary-compressing the content without their CDN or load balancer having to have implemented it.
Right, that's a reasonable workaround for CDNs that don't know about this spec. But wouldn't we rather the CDNs could implement the spec and calculate the delta at the edge? Wouldn't that be the desired end state? Perhaps I'm wrong, or perhaps I've wandered into an architectural question bigger than this issue.