httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: Inserting protocol filters into chains with no resource filters
Date Tue, 11 Jan 2011 22:33:33 GMT
On Tuesday 11 January 2011, wrote:
> I've encountered an issue with add_any_filter_handle().  Let me
> explain the background.
> My understanding of filter chains is that they form a linked list
> with three entry points.  The entry points correspond to resource
> filters, protocol filters
> and connection filters.  Depending on the filters present, these
> entry points can overlap, but the order must be: resource filters <=
> protocol filters <= connection filters.
> I have a module that sets up a filter chain from scratch, with
> perhaps unusual characteristics.  I've noticed that if the chain
> has no resource filters and you
> try to add a protocol filter, then the protocol filter entry point
> moves to accommodate new filter, but the resource filter entry
> point remains unchanged.
> For example, before add_any_filter_handle() the chain looks like
> this: filter1 (protocol)  <- resource filters <- protocol filters
> filter2 (connection) <- connection filters
> After adding another protocol filter:
> new filter(protocol) <- protocol filters
> filter1 (protocol) <- resource filters
> filter2 (connection) <- connection filters
> I'd expect that traversing the chain starting at the resource
> filters entry point would pass by every filter, hence the expected
> result would be:
> new filter(protocol) <- resource filters <- protocol filters
> filter1 (protocol)
> filter2 (connection) <- connection filters
> I've extracted the add_any_filter_handle code from httpd trunk and
> created a unit test.
> ?revision=965325&view=co
> With my "patch" enabled, add_any_filter_handle() functions as I'd
> expect.  When the patch is disabled, via conditional compilation,
> the test2() function fails.
> I'd like to know if there's a valid reason for the current
> behaviour, or if the fix I've posted is appropriate.

I think what you describe is a bug.

There is at least one issue with your fix: r_filters and p_filters can 
be NULL. If I change the if clause in your patch to

if (r_filters && p_filters &&
    *r_filters == *p_filters && outf == p_filters)

it passes the test suite.

Apart from that, I haven't tried to understand add_any_filter_handle() 
well enough to tell if your fix is correct.

View raw message