> >> the way Apache chose to work around this was to add the filter_init >> callback >> to allow filters to add processing just prior to content generation. >> presumably, this is where filters could call ap_update_mtime or >> whatnot to >> add their information in the conditional GET calculations. the >> decision to >> use filter_init over putting ap_meets_conditions logic in its own >> filter was >> made in order to let the (presumably) most popular case - >> default_handler + >> mod_deflate - be as fast as possible, > > > This isn't entirely true. Yes, there is the filter-init callback, but > the other > accepted solution is to create a handler/filter hybrid (such as the > cache code). > The handler participates in making sure all the pieces and parts > required to > make a good decision are present, then the filter acts on the final > decision. > The handler can insert the desired filter.
I can see how that might work in some (even most) circumstances. but requiring filters to rewrite things like default_handler just because it makes it difficult to behave properly is asking a bit much. but default_handler and mod_autoindex are the only core things I can think of at the moment :) > > I believe the decision was also motivated by a desire to make the 304 > as streamlined as possible. Why run a 304 through *all* of the filters and > associated processing if the effort was just to be thrown away and a 304 > sent. precisely because you can't possibly know whether the 304 is valid until every potentially-content-altering filter has run - because we're offering a filtering API (as opposed to only supporting core filters), each third party filter can use _absolutely whatever criteria it wants_ to decide whether it will alter the content. I could give an(other) example, but I fear people on the list are tiring of this already, so I'll give it a rest :) > I agree that this is a potential pitfall. Perhaps not all situations can be > addressed by a handler/filter hybrid. But moving the meets_condition logic > to a filter doesn't address all of what my fix does. ... > My feeling right now is to commit > my patch and address the meets_condition question as a seperate issue. yes, I'm terribly sorry that the two got jumbled together, thus distracting potential reviewers away from your work - it's entirely my fault. so, I'll end it here :) --Geoff
