My list insertion code was wrong, which was causing this bug. Also,
this patch is required even without the rest of the
mod_dir/mod_negotiation patch. We have a bug, it allows a connection
filter to be added and never called. Try this:
Crete a request
Add connection filters
Add request filters
Add connection filters
The second set won't be added. I am fixing this now, it was a simple
mistake of where the if was done.
> I still fail to see why you think protocol filters would solve
> this problem. I've explained my reasoning behind why I think this
> isn't a good idea. I've also pointed out a suggestion that I
> believe would work that is rather simple and would increase our
> flexibility. I'd like to hear your reasons why my approach isn't
> feasible.
Because your suggestion makes it even harder impossible to write
modules. Module authors have already told us which filters should
continue through redirects and sub-requests. They did that through
using a different filter type. Why should they then have to repeat that
information in a function?
Hooks are not the solution to every problem. We already have people
complaining that there are so many hooks that they don't really know
what is possible with the server, nor do they know what they have to do
to make their modules work. Why would we add more hooks at this point
when there are other cleaner solutions?
However, I have been tracing this patch. The problem is that we are
using a simple list, but we don't actually have a simple list. We have
multiple lists converging in one place. The subrequests are breaking
the filter list now, because I have converted this to a doubly linked
list. I will be working on fixing this ASAP, but it may a few hours to
fix.
This has VERY little to do with the mod_dir/mod_negotiation bug though.
That fix was put committed in the commit before this one. This patch
fixes a major problem with our filter lists, and we need to have this
fixed.
Ryan
