Another problem with filters design is the init_filter function. I forgot the details, I hope Geoff can give them, as he has messed with it.
the issue is primarily with default_handler.
for instance, there is currently a bug in the interaction between mod_include and default_handler: if default_handler decides a 304 is in order, it sets an ETag header, even if mod_include (rightly) stripped it in the original 200 response. I've posted a patch
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105120818606501&w=2
and a bit more explanation, but the patch is really a hack - there probably needs to be an ETag generation API so that modules can work together in generating the ETag.
other issues that I have found center around 304s. I can go into more detail here if people like, but the overall idea is that filter_init is sometimes too early to make intelligent decisions, especially when you want to operate only on a certain mime type. just about all of these, though, could be easily solved by moving ap_meets_conditions logic to it's own filter, which was the original proposal before filter_init won. as I use output filters more, I'm finding that I really don't want default_handler (or any content handler, for that matter) making conditional GET decisions when output filters are involved, even if it means that the server is slower when only serving compressed, flat files.
HTH
--Geoff
