httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <>
Subject Re: [Patch] Hook to allow insertion of filters during error processing
Date Thu, 11 Dec 2003 19:07:38 GMT

Geoffrey Young wrote:
> 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 :)

Not rewrite any existing handlers, and certainly not rewrite the default_handler,
just create and insert their own handler that runs before the default_handler.
These types of handlers can be very simple and easy to write. Mostly they would
just check some data (maybe headers), set some flags or headers, and install a
filter for later processing.

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

Agreed, doing the short circuited version is not 100% accurate under every
circumstance. I think the hope was that between filter_init and handler/filter
hybrids we could cover all the exception cases. It might not be the easiest
method, but it provides the easy and optimized approach for most of the default
cases. There was a lot of effort to avoid programming the default behavior to
the handle exception case since this adds a performance burden on the normal path.
This may be a case where we decided to shortcircuit and shouldn't have.

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

You brought up a good, and related, issue. That's your fault. :)

> so, I'll end it here :)

I think the meets_condition issue you bring up is valid and needs to be talked
about and addressed. Please don't let it drop. I just think my patch covers
more than the 304 case that caught your attention and is thus a somewhat
seperate issue. (related, but seperate) I didn't mean my declaration to commit
as an end to discussing your issue.

> --Geoff

Paul J. Reder
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

View raw message