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
