Graham Leggett wrote: > This is a cryptographically signed message in MIME format. > > --------------ms4949D2B6D144F9280EAD0AAA > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Ian Holsman wrote: > > >>This directive is >only< on the incoming request, If I'm caching results >>of a expensive call to a backend server, why should some piddly client >>tell me to re-get the info, forcing a subsecond response to become a 10 >>second one ? >> > > Because the HTTP protocol says it can. > > Part of the reason for the existance of mod_cache is to solve this > problem. The client comes in and says GET /expensive HTTP/1.1. Mod_cache > uses it's freshness calculations to determine whether a cheap previously > cached copy gets returned. But: if the client says GET /expensive > HTTP/1.1; Cache-Control: max-age=0; then the client gets the expensive > up-to-date version - why? Because the user specifically wanted it.
That's way by default it's not enabled. I'm trying to cater for the case when the mean spirited service provider doesn't care what the user 'asks' for their going to get what there given. ;-) > > If your app takes 10 seconds to generate a page on each hit, then the > app is broken and should be replaced by something which updates a flat > file every so often. This will ensure that no client will ever have to > sit out the 10 second regeneration time should the cache need to be > refreshed for whatever reason. > actually my plan is to cache flat-file. believe it or not one of our major bottlenecks in now retrieving the file off NFS after something else had written it to a flat file. If you want I can give you a more detailed explanation on how our website is setup and how I see the mod_cache helping (offline) > In addition the v1.3 cache contains a design flaw, where until the > expensive 10 second request is complete, all further requests will also > generate a 10 second query. This can cause some nasty load spikes on > servers until at least one query is complete, and a cache file becomes > valid. > > >>I'll make the directive a bit more clear maybe >>'CacheIgnoreIncomingCacheControl' >>and put a message who this breaks RFC compliance >> > > I think a better idea is to create a mechanism to override the freshness > calculations. For example, you might say "all files under this regex > will have a freshness lifetime of 3600 seconds, regardless of > Cache-Control from the backend server". Or even better - just make sure > your backend server generates Cache-Control headers correctly. I agree here. that's what the optional function is meant for.. someone else can implment the freshness calculations and URI -> cache-key conversions BTW .. the backend server we can control and fix and hence why the directive doesn't do anything on the backend response. ..Ian > > Regards, > Graham >
