httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: cache trouble (Re: [vote] 2.1.9 as beta)
Date Fri, 04 Nov 2005 10:28:22 GMT
Nick Kew wrote:

> I'm not convinced by that either.  In fact, I dislike the whole "run it in a
> quick handler" principle - it runs a supertanker through the KISS principle,
> and has consequently left us with a cache that never really worked.
> Even if we fix this, it's sure to have a high bugrate for the forseeable
> future precisely because it violates KISS.

The principle behind running it in a quick handler in the original 
design was so that the cache could work as a 100% standards compliant 
HTTP/1.1 caching proxy, as described in section 13 of RFC2616.

RFC2616 is well understood, and already nails down all security issues 
to do with proxy caching. Making the cache follow a widely accepted and 
known to work standard follows the KISS principle.

Over time, the cache has slowly moved backwards from being as far 
forward on the frontend of the filter stack as possible, to further and 
further back into the webserver itself.

In the process, the cache becomes less and less compliant with RFC2616, 
which has made it more difficult to understand and more complex to 

The httpd cache is simply yet another cache in the chain of HTTP/1.1 
caches that are typically present when a browser accepts a page from a 
website. The authentication issue is handled by RFC2616 already, and as 
long as httpd mod_cache conforms to the correct headers handling, and 
works like the other proxies in the chain, then authentication is not a 


View raw message