Possible scenerio:
Serving cached content:
- lookup uri in cache (via md5?). - check varies - a list of headers to vary on - caculate new key (md5) based on uri and clients value of these headers - lookup new uri in cache - continue as normal
Caching an object: -see if object has been cached before by looking up uri in cache -do the Vary's match? -no, discard old entry(?) and create new uri entry -yes, generate new key based on client values -continue as normal
I wouldn't discard the old entry, but store it as a variant to also cache. But, yes, a two-level scheme like this may make sense.
This allows us to cache the gzipped and non-gzipped versions - which is what we'd want.
The thing that sucks is if you vary on User-Agent. You wind up with a ton of entries per uri. I cheated in another modules by "varying" on an environmental variable. Kind of like this:
BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip
and just "vary" on no-gzip (1 or 0), but this may be hard to do just using headers...
Note that BrowserMatch with regexp's is ridiculously expensive. Minimizing the need for that would be goodness, I think. -- justin
