httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] link-based filtering
Date Mon, 26 Jun 2000 19:49:06 GMT
On Mon, Jun 26, 2000 at 12:24:36PM -0700, wrote:
> > > for example:
> > > 
> > > CGI  ->  SSI
> > > 
> > > CGI outputs:
> > > 
> > > "<!--"  in the first write
> > > "#exec" in the second write
> > > "cmd=foobar" -->"  in the third write
> > > 
> > > Any sane implementation of mod_include is going to just use an iovec for
> > > those.
> > 
> > I believe that a sequence of ap_lputs() calls will be more common. An iovec
> > could certainly be used, but it won't give you a tremendous speed advantage
> > since the BUFF is in the way. Your iovec will fall into the BUFF first, then
> > be chunked out in one shot.
> It isn't mod_cgi that is going to use the iovec, it's mod_include.  That
> is, unless mod_include is going to memcopy all of those into a BUFF.

Copying into a BUFF is what happens today, and I see no reason that it
wouldn't or shouldn't in the future.

But heck, if we really want to write iovecs, then it would be
straight-forward. There isn't a need to complicate the whole situation just
to get a bit of iovec capability.

> > Coolness. I have an updated patch in a moment here, too. You may want to
> > review that for problems before digging in for a lot of coding time.
> Too late.

Oops :-)

When you post your patch, please hilite the *differences* from my patch.
That is where the discussion will take place.

> Plus, as an advantage to the patch that I have almost done,
> most of the complexity of my patch goes away,

Ah. This is goodness.

> and most of buff.c can be
> removed and replaced by modules.  Plus, mod_ssl becomes simplistic.  

I suspect either patch set will allow this.

> This
> patch is a relatively obvious next step to my previous patches, except
> that it becomes recursive.  I think you'll like what you see.  :-)

All righty :-)

But I'm going to have to say, that if you've switched over to a recursive
style, then you will have eliminated any of the technical problems that I
had with your original patch. That means we will simply be discussing
stylistic options for the filtering implementation. That could be a good or
a bad thing :-)

> > I avoided that to keep the patch short and understandable. I had hoped that
> > it was obvious how to do this, and that a simple function would be written.
> The addition was obvious.  I just fear that once you add it, you'll see
> that it looks a lot like the hooks stuff.  If it looks at all like the
> hooks stuff, then my next patch becomes absolutely beautiful.  :-)

Nope. It is very simple, and doesn't look at all like the hooks. No need for
that. Since a module can register their "install_filters" hook with a
specific ordering, then any filter addition will follow that ordering. I
also suspect that all filtering will be done using SetFilter or the like,
which defines a specific ordering to the addition of filters.

In other words, it still remains a simple, linked list.

> Give me about an hour to finish coding and test.  And I should have a
> patch by the end of the day, unless something horrible crops up.

Okay. But I will say again: you can save that hour or so, as I believe my
patch address all of your technical concerns.


Greg Stein,

View raw message