Ruediger Pluem said: > So I created a patch which defines four filter handles instead of two: > > CACHE_OUT / CACHE_SAVE as AP_FTYPE_CONTENT_SET+1 filters and > CACHE_OUT_SUBREQ / CACHE_SAVE_SUBREQ as AP_FTYPE_CONTENT_SET-1 filters > > Depending on the type of request the patch now inserts either the > AP_FTYPE_CONTENT_SET+1 > or the AP_FTYPE_CONTENT_SET-1 filter. > > Comments / Thoughts?
I've seen the location of the cache filters move up and down the chain for a long time now, and I wonder if this moving up and down is such a good idea. My original intention when I put together the CACHE_OUT and CACHE_SAVE filters was that they ran first and last on the filter chain. In other words, mod_cache could be thought of as a completely separate HTTP/1.1 proxy cache "bolted on" to the frontend of httpd, but as independant as possible of the httpd server itself. HTTP/1.1 already caters for transparent frontend proxies and describes the behaviour when there is authn and authz, variants of the same URL, etc. Bolting the cache onto the frontend means that as long as the cache follows the RFC, it will work predictably and securely, as there are enough transparent caching proxies out there to show that HTTP/1.1 works. Over time, for various reasons, the cache code has moved further down the stack. This has complicated the cache code, because now instead of purely following HTTP/1.1's spec, it must now take into account extra details like special authn handling, variant handling, etc. I would prefer to see a solution to this problem that moves closer to the HTTP/1.1 spec for transparent proxies. Regards, Graham --
