Minor breakage with ap_add_filter

[rb...@covalent.net]

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.

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?

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Minor breakage with ap_add_filter

[Tony Finch <do...@dotat.at>]

Greg Ames <gr...@raleigh.ibm.com> wrote:
>
>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?.  

BUFF will go completely asap. We aren't that far from killing it.
Buffering over pipelined requests is so simple that code duplication
shouldn't matter.

Tony.
-- 
en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y    dot@dotat.at
eatp o v eiti i d.    fanf@covalent.net

Re: Minor breakage with ap_add_filter

[rb...@covalent.net]

On Thu, 21 Sep 2000, Greg Ames wrote:
> 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?.  

BUFF needs to go away.  I have been saying that for a while.  It is
cramming too much into one type.  By separating out the BUFF logic into
four or five simple filters, we remove a lot of complexity, and make
things more modular.

> > 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.

Cool, I'll make the change later today.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Minor breakage with ap_add_filter

[Greg Ames <gr...@raleigh.ibm.com>]

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