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 implement.
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 problem.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
