httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: filter API spec
Date Thu, 04 Sep 1997 05:14:53 GMT
On Wed, 3 Sep 1997, Dean Gaudet wrote:


> You should remove the cookie from bfilter, and pass it to bpush
> separately.  That way bfilters can be constant globals exported by a
> filtering module.  In your above API you would have to make a copy of a
> constant global and tweak the cookie. 

Valid point.


> Well, in reality you don't need the fd and fd_in at all ... since the
> bottom-most layer can be a filter which is a wrapper for the unix
> function calls, and its cookie would include the fds.  All you need
> in the BUFF structure is:

Okay, sure. None of the document is intended to be an actual
implementation, just some ideas.


> > The internal write()-like function (buff_write()) would look something
> > like this:
> > 
> > int buff_write(BUFF *b, char *c, int l) {
> >     /* Are we a stacked filter? */
> >     if (b->down) {
> > 	if (b->bf.write)
> > 	    return bf.write(b->down, bf.cookie, c, l);
> > 	else
> > 	    return buff_write(b->down, c, l);
> >     }
> > 
> >     /* We're the bottom of the stack:
> >      * do what the current buff_write() does right now
> >      */
> > }
> With my above modification it'll always call b->filter.write.

No, actually. It should look like this, to deal with the fact that the
write function may be conveniently NULL :

int buff_write(BUFF *b, char *c, int l) {
    if (b->filter.write)
        return b->filter.write(b->down, b->cookie, c, l);
	return bwrite(b->down, c, l);

And, yes, it should be bwrite, not buff_write that it calls, since that's
should do all the right things, including buffering it turned on. That
was wrong in the original document.


> > The internal bclose, bflush, etc... would be similar. The internal bread()
> > would have to be backwards (finding the bottom BUFF, and looking at
> > previous elements - this is why an up element in BUFF is necessary),
> > since reading happens bottom-up, wheras everything else is top-down.
> Uhhh ... no this doesn't seem right at all.  A read still occurs on
> the top, which might be satisfied from the buffer, if not then it goes
> one layer down.  That might be in the buffer, if not it goes one layer
> down.  In effect the first read will nest all the way down, and then
> come back up filling buffers along the way.  But you only need a down
> pointer since this is all recursion.

Yes, yes, yes. Ed and I realized this after the document was sent. We had
thought it out, realized that the data had to go backwards, and flipped
it, not realizing that, in fact, it already was. So we ended up reversing
it twice.

> > void my_close (BUFF *b, void *) {
> >     bclose(b);
> > }
> I see no reason for a close method in the filter.  bclose is simply
> a series of flush, unattach, bpops.

Except that there is no pop function we defined. Close is better. You
need to be able to define a certain close to the filter, to call the
system-level close, for example. You can't always make the presumption
that a given message (write, flush, close, whatever) is always going to
go all the way down to the bottom; a filter in the middle might redirect
all output somehow to something else (no, I don't know why), so the code
shouldn't assume that it should propogate the close to the bottom.

> > The problem is the read buffer. If a filter is popped, and there is
> > still data in that filter's input buffer, what do you do with it?
> This is an application error I say.  Don't do anything complicated at
> all here until you actually find this to be a problem in practice.

It's an application error if it reads more data than it needs, I
agree. It's not an application error if you have input buffering turned
on, where you have no control over how much data is stored in your
buffer. Consider mod_cgi and pipelined requests.

Besides, it's relatively trivial to, if there is data in the input
buffer, to set all the filter functions to NULL, mark it as "popped", and
all the data will be retained.

-- Alexei Kosut <>

View raw message