httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Allowing modules to add input filters is broken
Date Mon, 21 May 2001 19:39:24 GMT
On Mon, May 21, 2001 at 11:52:14AM +0200, Graham Leggett wrote:
> Greg Stein wrote:
> > If filter types are equal, then order is dependent upon insertion, which
> > falls back to the insert_filter ordering.
> > 
> > So... you can correct your filtering ordering by adjusting its type and
> > inserting it whenever, or you can have the same type as the core filters and
> > just make yourself run before the core filters.
> But as Ryan pointed out, and as the code shows the HTTP_HEADER filter is
> added before the insert_filter hook, so it's now impossible to add
> AP_FTYPE_HTTP_HEADER filters that do anything.
> I posted a patch to fix this.

Moving the insertion of those filters to the insert_filters hook is the
right thing to do! Don't get me wrong.

I was trying to point out that we've got a lot of flexibility in how the
filters are inserted, and how to get them ordered.

> > I'd say make your insert_filter hook APR_HOOK_MIDDLE and use
> > AP_FTYPE_HTTP_HEADER - 1 for the type. Then it will run just before the
> > HTTP_HEADER filters.
> So adding a -1 will place the filter before the last filter?

Using AP_FTYPE_HTTP_HEADER-1 will put your filter "before" *all*
AP_FTYPE_HTTP_HEADER filters. No matter *when* you end up calling "add

In other words, it is *much* safer to use the -1 on the filter type. You
don't have to worry about whether your add_filter comes before/after the
core's add filter. And when you think about it: you shouldn't *have* to know
when the core does it. Really: the core is adding filters, but why should
you care?

> What if
> someone else tried to add an AP_FTYPE_HTTP_HEADER filter in another
> module without a -1? Now it would no longer work,

Huh? Ah. You mean that you could add some headers, a filter would run after
you (doing what?), and then the regular HTTP_HEADER filters would run.

I'm not sure that I see a problem with that. And recognize: it will *always*
be the case that somebody could insert a filter between yours and the core's
filters. You shouldn't have to care/worry about that.

Consider: if you use HTTP_HEADER and happen to beat the core's insertion, to
get yours "in front"... there could be somebody that adds an HTTP_HEADER
after you, but before the core gets its chance to insert filters.

So if you can't truly prevent a filter from coming between you and the core
filters, then don't even bother trying. And to isolate yourself from
"timing" changes in filter insertion, it is best to use the -1 on the filter
type to simply place yours before the core filters.

> and it would not be
> clear as to why. In addition, AP_FTYPE_HTTP_HEADER filter would have to
> work differently to the other filter types.

I'm not clear on "why" for that last statement. We can't/shouldn't special
case any of the types. They are only there to assist with ordering.


Greg Stein,

View raw message