httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: fix t/ssl/http.t
Date Tue, 02 Apr 2002 16:43:21 GMT
> 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 <jerenkrantz@ebuilt.com>
> To: dev@httpd.apache.org
> Subject: Re: httpd-test + cvs head
> Message-ID: <20020307094227.GM24710@ebuilt.com>
> 
> ...
> 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




Mime
View raw message