httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
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
</Directory>

(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


Mime
View raw message