The Vary header puts some new constraints on content revalidation.
In the exact-match only level Vary does not change the vay content-revalidation works, except that ETag from the exact match cached entity should be used if available to catch the case where the server-site selection algorithm has changed.
To fully support the potential of Vary, the cache must implement ETag indexes, and use this to build a "If-None-Match" list of entities when validating it's cached objects or when needing to query the origin for the correct entity for a request where none of the cached request headers exacly match the current request.
The ETag list is used on re-validations to allow the server to indicate changes in the mapping between request headers and cached objects.
The ETag list is used on fuzzy matches to allow the server to indicate that one of the already cached variants are valid for the request.
Note: To be able to do this, the cache must be able to index the ETag headers for all the cached entities representing the requested resource. This might not be possible for all caches due to how the cache storage is maintained.