httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: filter_init was Re: Time for 2.2?
Date Thu, 04 Sep 2003 12:52:05 GMT

> I, for one, would appreciate more details to better understand the 
> needs.  I'm not clear where the mime type fits in.  

well, say you have an output filter that should only operate on a particular 
mime-type - like the mod_blanks that keeps coming up here.  ideally, the 
filter should be able to do at least few things: remove (or weaken) the 
ETag, alter Last-Modified, and do it's filtering.  the first two need to 
happen in filter_init because of default_handler and its logic, but with an 
unknown content-type the filter is in a quandry - if it calls update_mtime 
but doesn't run (not html) then it affected the cache status unnecessarily, 
but if it doesn't call update_mtime() then default_handler might return 304 
before the filter can insert itself.  the etag issue is similar.

this is a real life scenario, btw - something I've been working on :)

 > Is it that
 > filter_init isn't called for AddOutputFilterByType filters?

I hadn't tried that, it would be interesting to see what ends up happening 
on AddOutputFilterByType filters when the content is a cgi script and 
content-type differs from DefaultType.

>> 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
> Hmm.  Would that filter be a CONTENT_SET (or PROTOCOL?) filter?  If it 
> thinks the response shouldn't be sent, would it throw away the response 
> (so far) and send down the 'right' bits for a 304?  Might work, but that 
> seems rather late to make that decision.  -- justin

well, I was thinking something along the lines of the C-L filter (whatever 
that is :)  basically, if everybody calls update_mtime but leaves 
set_last_modified for the filter then each handler and filter gets the 
chance to add its criterion to Last-Modified without worrying about another 
module sending a premature 304.  no_local_copy could be used when one 
participant knows what it is doing negates all caching.

granted, yes it seems late in the process if you're taking the time to 
compress a flat file only to send a 304 after, but as output filters get 
more complex, the non-content altering deflate model becomes the only 
circumstance I can think of where you actually desire the current behavior.


View raw message