I almost tried to snip the comments below in my reply, and there was nothing
I could clip out - thank you Graham for explaining so clearly the entire design
principals of how and why mod_proxy does exactly what it does.
It leaves us wondering; how can allow from/deny from n.n.n.n be mapped to
RFC 2616 semantics, or at least, without running the many server hooks on
later requests? The only way I can see, is that we should have any more
explicit allow from/deny from leave a marker in the request record from that
authorization phase, and mark it nocache if the request doesn't otherwise
set the authentication required headers.
Thoughts?
Graham Leggett wrote:
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
--
