httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Filter Breakage is Re: cvs commit: httpd-2.0/server core.c
Date Mon, 04 Mar 2002 15:07:03 GMT
> I now have two further problems.
> 
> 1) Since fast_redirect() is called from a hook, but all hooks are run
> on this "new" request - it is possible that some hooks are left to
> be run from the original request.  This causes a problem for the
> AddOutputFilterByType hook (core_filters_type) since it is a fixup
> as well and is run after the mod_dir/mod_negotiation hooks.
Therefore,
> when using this directive, it adds each filter twice causing segfaults
> and infinite loops.  Oops.
> 
> We could play with hook ordering, but I'm pretty sure that's the
> wrong thing to be doing.  Of course, I'm advocating removing
> fast_redirect for precisely this problem.

I've got the problem that I just don't see that behavior.  I have add an
AddOutputFilterByType directive to my htdocs directory, and I requested
GET / HTTP/1.0, and I received my page back successfully.  I need a
config that will reliably reproduce before I can fix this.

> 2) This code still can't handle filtering order properly across
> sub-requests.  There are two problems with this approach.  The
> first is that the lists aren't distinct and are corrupted as we
> generate the subreqs.

The filter chains must be "corrupted" as we generate subrequests.  The
problem is that we have a single chain, but we need to hook into the
middle of the chain as we go.  This has always been a problem with the
filter chain, but it wasn't as obvious when we had a singly linked list.
I have chosen to make the prev pointer always stay on the same chain, so
that a sub-request is literally inserting itself into the filter chain.
I haven't had time to test your config that is causing you problems, but
I will as soon as I get to the office.

>  The second problem is that I believe it is
> possible for a configuration to add a protocol-level filter (say,
> mod_headers or mod_deflate), and this new semantic does not
> support that properly (probably due to the assumption that
> protocol filters can't be inserted in a subreq).

Neither mod_headers or mod_deflate should be protocol level filters.
They both operate specifically on individual resources, and should be
resource level filters.  Change that and this problem will go away.

> Hope this provides some explanations as to the problems I'm
> seeing.  Again, I'm not at all sold on this proto_output_filters
> trick as I don't think it will solve our problem.  However, I'm
> willing to wait for Ryan to fix it because he seems pretty sure
> that this will work, but I'm definitely concerned about the extra
> complexity we're introducing.  -- justin

The problem is that we are removing complexity, not adding it.  The
problems that we have seen so far have all been to a number of hacks
that we have added to get error pages and everything else correct.  In
EVERY case so far, we have solved a seg fault or loop by not adding a
filter in a case where it didn't make sense to add it anyway.

Also, and please be incredibly clear about this.  The bugs that you are
seeing now, have NOTHING what so ever to do with the protocol filter
concept.  The bugs that you are seeing now are 100% related to trying to
fix the problem of losing filters when they are added at the wrong
stage.  If you don't believe me, go back to Saturday night's tree before
my last commit that night.  That had the protocol filters, and they
worked correctly.

Ryan



Mime
View raw message