Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Reply-To: <rbb@covalent.net>
From: "Ryan Bloom" <rbb@covalent.net>
To: "'Justin Erenkrantz'" <jerenkrantz@ebuilt.com>,
	<dev@httpd.apache.org>
Subject: RE: Filter Breakage is Re: cvs commit: httpd-2.0/server core.c
Date: Mon, 4 Mar 2002 17:11:23 -0800
Organization: Covalent Technologies
Message-ID: <011301c1c3e2$aa83bcb0$7f00000a@KOJ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20020305010409.GZ24710@ebuilt.com>
Importance: Normal

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

Just MultiView doesn't cause it, that is the case I was using earlier.
I have reproduced the bug below, and I started tracing it, but I was
side tracked by things blowing up.  I will be fixing it tonight.

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

My argument is very simple.  There are no protocol filters that should
actually be protocol filters that make ANY sense at all being added for
a sub-request.  The definition of a protocol filter is something that
doesn't operate on a specific resource.  The definition of a sub-request
is an internal request to return a specific resource.  The two concepts
are by definition incompatible.

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

Well, before the protocol filters mod_dir and mod_negotiation didn't
inherit filters.  After, they did, and the bugs that I am hunting now
didn't exist.  These bugs were only added when I started to fix the
filter insertion code.  So far, most of the bugs with the filter
insertion code have been fixed by removing duplicate insertions which
never should have been there.

Ryan