On Mon, 21 May 2007, Graham Leggett wrote:
Since max-age=0 requests can't be fulfilled without revalidating the
object they don't benefit from this header rewrite, and requests with
max-age!=0 that can benefit from the header rewrite won't be affected
by this change.
Am I making sense? Have I missed something fundamental?
At first glance, doing this I think will break RFC2616 compliance, and if
it does break RFC compliance then I think it should not be default
behaviour. However if it does solve a real problem for admins, then having
a directive allowing the admin to enable this behaviour does make sense.
Why would it break RFC compliance? This request will never benefit of
the headers being saved to disk, and the headers returned to the
client should of course be those that resulted of the revalidation of
the object. The only difference is that they aren't saved to disk too.
The only difference I can see is that you can't "probe" that the
previous request was a max-age=0 by doing max-age!=0 request
afterwards...
Zooming out a little bit, this seems to fall into the category of "RFC
violations that allow the cache to either hit the backend less, or hit the
backend not at all, for the benefit of an admin who knows whet they are
doing".
A simple set of directives that allow an admin to break RFC compliance
under certain circumstances in order to achieve certain goals does make
sense.
Yup. CacheIgnoreCacheControl is one of those, we use it on the
offloaders that only serves large files that we know doesn't need the
RFC behaviour.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---------------------------------------------------------------------------
Sir, We are receiving 285,000 Hails. รพ Crusher
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
