> 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
|