Brian Akins wrote:
That's two hits to find whether something is cached.You must have two hits if you support vary.
You need only one - bring up the original cached entry with the key, and then use cheap subkeys over a very limited data set to find both the variants and the header/data.
How are races prevented?shouldn't be any. something is in the cache or not. if one "piece" of an http "object" is not valid or in cache, the object is invalid. Although other variants may be valid/in cache.
I can think of one race off the top of my head: - the browser says "send me this URL".- the cache has it cached, but it's stale, so it asks the backend "If-None-Match".
- the cache reaper comes along, says "oh, this is stale", and reaps the cached body (which is independant, remember?). The data is no longer cached even though the headers still exist.
- The backend says "304 Not Modified".- the cache says "cool, will send my copy upstream. Oops, where has my data gone?".
The end user will probably experience this as "oh, the website had a glitch, let me try again", so it won't be reported as a bug.
Ok, so you tried to lock the body before going to the backend, but searching for and locking the body would have been an additional wasted cache hit if the backend answered with its own body. Not to mention having to write and debug code to do this.
Races need to be properly handled, and atomic cache operations will go a long way to prevent them.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
