I really wasn't going to get into this, but oh well.
The flush support is almost always used incorrectly in HTTPd. The purpose
of the flush bucket is simply to _force_ data to be sent to the user.
It's purpose is to say: "There is no more data coming for a while, so send
what you have to the user while I keep generating more data". That isn't
the case you have here.
Here, you have a poorly behaved filter that isn't watching how much it is
caching. Take the simple (and inane) case. I have a 100 MB static file
that I didn't compress on disk, but I want it sent to the browser using
mod_deflate. If mod_deflate buffers the whole thing, then I have a
problem, because it is going to take a while. If you "fix" this in
mod_dav, then _every_ other content generator that sends data through
mod_deflate needs the same fix.
Filters have the responsibility to watch how much they buffer and take
steps to make sure it is as little as possible. So the fact that mod_dav
is alredy doing the wrong thing isn't really a good argument.
It is really simple. Take a look back at the archives from when filtering
was designed, and you will see that we were very clear that filters had to
be well behaved. They couldn't just buffer the data until they had it
all. Doing so killed server performance and memory use. We worked very
hard to make sure that the content_length filter didn't do it, and if
mod_deflate is doing so, then it is wrong.
Ryan
On Tue, 15 Jul 2003, Sander Striker wrote:
> > From: Justin Erenkrantz [mailto:justin@erenkrantz.com]
> > Sent: Tuesday, July 15, 2003 11:26 AM
>
> > --On Monday, July 14, 2003 11:55 PM -0700 Greg Stein <gstein@lyra.org> wrote:
> >
> > > What Ryan said. The handler shouldn't ever say "force this to the network".
> >
> > Which I think is ridiculous for either of you to say when mod_dav already
> > calls ap_filter_flush to do exactly that. As I said earlier, I have a hunch
> > that it just needs one more flush call to solve this particular timeout
> > problem (right after the invocation of dav_send_one_response).
>
> I agree with Justin here. If mod_dav wouldn't already have flush calls I
> would see your point, but this is just plain silly.
>
> Also, mod_dav knows when it has reached a chunk boundary that makes sense
> to the client. How do we communicate this to the next filter in the chain?
> We don't. So apart from flushing, how do we prevent an endless wait on
> the deflate filter? Certainly, deflate could work with smaller chunks, but
> then it would be less effective.
>
> > Either ap_filter_flush is a valid solution, or it should be removed entirely.
> > You can't have it both ways. Requiring the addition of custom threshold code
> > to *every* filter is a cumbersome requirement. If you really feel that's
> > needed, then we should remove flush support to compensate. -- justin
>
> The man's got a point.
>
>
> Sander
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 14:46:05 2003