> On Tue, 2 Apr 2002, Ryan Bloom wrote: > > > It is perfectly possible for a filter to remove itself. In fact, the > > byterange filter relies on that ability to work correctly. While I > > would be interested to know what happened to make that case fail, if the > > patch below works, then +1. > > i was thinking of this comment from justin: > Date: Thu, 7 Mar 2002 01:42:27 -0800 > From: Justin Erenkrantz <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: httpd-test + cvs head > Message-ID: <[EMAIL PROTECTED]> > > ... > However, mod_ssl is bogus. The ssl/http.t test is interesting > since it causes mod_ssl to remove itself via > ap_remove_output_filter() (mod_ssl.c:358). Since mod_ssl is a > connection filter, our new strategy is that it can never be > removed. Ooops. Since it doesn't have access to the request_rec, > it can't destroy its predecessor's reference to itself. Perhaps > this means we *do* need the ->prev. > ... > > is this still true? (note: mod_ssl.c:358 is now 421)
Nope, I fixed this. The problem was that we couldn't remove the first filter in any of the three lists, because the previous filter structure wouldn't be updated. The solution was to walk the filter list each time we tried to remove a filter. This allows us to find the correct filter entry and set the pointers appropriately. Ryan
