httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [Patch] Hook to allow insertion of filters during error processing
Date Thu, 11 Dec 2003 18:22:28 GMT

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


View raw message