httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: Time for 2.2?
Date Wed, 03 Sep 2003 19:33:54 GMT

> 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


Mime
View raw message