Henrik Nordstrom wrote:
But the unique identity of the response entity is defined by request-URI + ETag and/or Content-Location. The cache is not supposed to evaluate Accept-* headers in determining the entity identity, only the origin server.
However, on an initial request (ie, non-conditional) we do not have an etag from the client, we only have info like Host, URI, Accept-*, etc. So, how would the cache identify which entity to serve in this case?
Please see RFC2616 13.6 Caching Negotiated Responses, it explains how the RFC intends that caches should operate wrt Vary, ETag and Content-Location in full detail.
I have read it many times.. In our case - cnn.com, etc. - we have to decided to be RFC "compliant" from the client to the cache server. From the cache to the origin, however, we are not as concerned. In a reverse-proxy-cache, this is not a big deal. However, in a "normal forward-proxy-cache," where one does not control both cache and origin, one must be more careful.
-- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
