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.
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.
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.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
smime.p7s
Description: S/MIME Cryptographic Signature
