Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: greg@raleigh.ibm.com
Message-ID: <39CA4CE0.6285B942@raleigh.ibm.com>
Date: Thu, 21 Sep 2000 14:01:04 -0400
From: Greg Ames <gregames@raleigh.ibm.com>
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: Minor breakage with ap_add_filter
References: <Pine.LNX.4.21.0009200306460.2046-100000@koj>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

rbb@covalent.net wrote:
> 
> The recent move of ap_add_filter("CORE",...) has outlined a potential bug,
> so I thought I would bring it up here and now, so we could all nip it in
> the bud.  The problem is that we are adding the CORE filter in the
> core.  This works fine for regular requests, but as soon as we have to add
> an SSL filter, this will break, because the SSL filter shouldn't require a
> core change.  I think the solution is to move the ap_add_filter calls from
> http_core's insert_filter routine to the post_read_request hook.
>
Yup - good point, if you assume that SSL must become a filter.  I can
think of other possible good designs, but filters could work.  

If it does become a filter, seems like BUFF should be decomposed further
to avoid duplicating code.  Buffering across pipelined requests, for
example, would be common to SSL sockets and regular sockets, right?.  
 
> I took a quick look at where the ap_add_filter call was added yesterday,
> and it is always just before the post_read_request hook is called.  I
> would like to add an AP_HOOK_REALLY_FIRST function to http_core, which
> will add all of the core filters.  The reason for the
> AP_HOOK_REALLY_FIRST is that we want to make sure that there is always a
> CORE filter on the filter stack when we call out to other modules.
> 
> Does anybody have a problem with doing this?  Does anybody see a hole that
> I missed?
> 
No, that sounds like a good start, until we become more experienced with
this stuff anyway.

Greg