> This patch allows mod_cache to cache a response that isn't > all contained in the first brigade sent through cache_in_filter(). > (This scenario happens, for example, with reverse-proxy requests, > CGIs, and various app server connectors.) > > Can someone familiar with the caching code please scrutinize > the patch and send comments? There's one known problem with > the code (details below), but it's otherwise ready for review. > > The way it works is: > > * If the first call to cache_in_filter() includes an EOS, > the operation is unchanged: put the response in the cache ( > assuming it meets all the other cacheability criteria) and > pass the brigade to the next filter. > > * If the brigade passed to cache_in_filter() doesn't have an > EOS, though, the filter now makes a copy of the brigade and > passes the original on to the next filter. In subsequent > calls, cache_in_filter() continues buffering up copies of > the buckets while streaming the response on to the next > filter in the chain. Once it finally sees an EOS, it > concatenates the setaside buckets into a single brigade > for storage in the cache. It then streams the last bit > of the output to the next filter. > > * If the response contains any bucket with length==-1 (an > unread pipe bucket, for example), the filter doesn't attempt > to cache it. (It's probably possible to add support for > this in the future.) > > The one thing that's missing is a check to avoid setting aside > too much data. If the total size of the setaside buckets would > exceed the maximum object size for the cache, cache_in_filter() > should immediately discard the setaside buckets and give up on > caching the response. What's the right way to implement this > check? It looks like the max object size is a property of each > specific cache implementation (mod_mem_cache, mod_disk_cache). > The first solution that comes to mind is to make each cache > implementation provide a callback function that says whether > it's willing to cache an object of size X. Is there a cleaner > solution? > > -Brian
Adding a callback/hooks sounds okay. An additional problem to consider is when a frequently requested resource does not return an EOS in the firet brigade and it turns out to be too large for the cache. We need a negative cache (what else would you call it?) to prevent mod_cache from attempting to cache the same object over and over. If the object is too large, create a negative cache entry. Consult the negative cache when the response is received to determine if mod_cache should even attempt caching. Bill > >
