httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Filter Breakage is Re: cvs commit: httpd-2.0/server core.c
Date Tue, 05 Mar 2002 01:04:09 GMT
On Mon, Mar 04, 2002 at 07:07:03AM -0800, Ryan Bloom wrote:
> > 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.

I think you need two levels of subreqs.  I was using the manual/
wich causes mod_dir->mod_negotiation.  In fact, I believe just
a MultiView will cause this (no need for mod_dir).  So,
/manual/index.html should trigger this.

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

Were you able to reproduce it?  As I indicated in a private email
earlier today, the following config is broken:

Alias /manual "/pkg/apache-2.0-cvs/manual"

<Directory "/pkg/apache-2.0-cvs/manual">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
    AddOutputFilter DEFLATE .html

(This config showcases all of the bugs I've seen.)

If you have the right patches (hinted at by my earlier message),
AddOutputFilterByType DEFLATE text/html would work, but that's
corrupted since the hooks are run twice.

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

Let's say I come up with some protocol-level filter that has
a legitimate use and I can't add it via AddOutputFilter.  Bogus.
You're ignoring the problem by restricting what filters we can
have.  Bad idea, IMHO.

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

Nope, I believe the protocol filters are essentially a no-op.  They
aren't doing anything because things are only added to
r->proto_out_filters when we run ap_run_insert_filters which is
after subreqs.  I'm not seeing any benefit by having proto filters -
they just seem to serve to complicate things.  -- justin

View raw message