Right. mod_dav's use of ap_filter_flush() is wrong. It should be using
ap_pass_brigade() to pass the brigade contents down the filter stack. As it
stands right now, we are flushing the content to the network via a FLUSH
bucket, returning from the handler, and Apache is then sending a brigade
with an EOS bucket. If we just pass our remaining brigade contents (before
function return in the two places where flush is called), then the EOS will
ensure the response is flushed to the network.
(in fact, I'll make this ap_filter_flush -> ap_pass_brigade change later
today... it is the right thing to do)
Cheers,
-g
On Tue, Jul 15, 2003 at 05:53:29AM -0700, rbb@rkbloom.net wrote:
>
> 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
> >
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 19:53:51 2003