httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Winstead <j...@trainedmonkey.com>
Subject Re: summary: issues for my filtering patch
Date Wed, 28 Jun 2000 16:35:40 GMT
On Jun 28, rbb@covalent.net wrote:
> 2)  The core imposes some sane restrictions on how much of the request is
> in memory by controlling the buffering.
> 
> Greg is proposing #1, I am proposing #2 (after much prompting and head
> beating from Roy).  My feeling, after having looked at this problem for a
> VERY long time, is that trying to just fit option 2 in after the current
> patch is applied is almost impossible.

What are the restrictions imposed by the core in this scheme?

> Using option #1 is not a good idea IMNSHO, because it allows stupid
> filters to take down the server.

I don't see how you're ever going to prevent that. People always
find ways to do stupid things. :)

> > that says "hey, here's the data to send, but don't send it until
> > I tell you its okay, because I'm going to be adding a header". But
> > all you've gained in that case is the ability for the later layers
> > to start processing the data instead of having to wait for the
> > layer that thinks it needs to see all of its input before it can
> > send on its output. (Which it will presumably do by sending all
> > the accumulated data at once, so each later layer gets called
> > once and doesn't have to do any buffering.)
> 
> By having a top level filter do the buffering it requires, we can actually
> get single or zero copy in.

It sounds to me like that is resolved just by defining the memory
life-cycle of a "bucket" to always end once it is written to the
network.

If some intervening layer needs to make a copy (to store for later
use, or to move it to an area it can change), I don't see how you
can avoid that.

I'm a little confused as to what you mean by "top level filter".
Is that closest to the network, or some distance away?

> > But it also just seems like an optimization. Like I said, PHP
> > didn't have any sort of output buffering until the latest version,
> > and although there was some grousing from users, they generally
> > accepted the limitation of not being able to add headers after
> > non-header data had been sent.
> 
> Again, it is how the buffering is done that is important.  Asking each
> module to implement their own filtering is asking for trouble.

Some modules (like PHP) are probably going to implement their own
buffering (which is what I assume you meant to say) regardless of
what the core does or provides. It doesn't seem like a good reason
to hold back filtering to me.

Jim

Mime
View raw message