httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: eek. poor chunking behavior.
Date Tue, 12 Sep 2000 14:28:06 GMT

> > EOS will work just fine here.  The EOS doesn't say that you have to send
> > the data to the network, just that there will be no more coming.  If the
> > buffering filter sees an EOS, it sends the data to the chunking filter,
> > which adds the filter chunk, and then it gets sent to core_filter, which
> > puts it in the conn_rec until the next request calls it's
> > core_filter.  This will work just fine.
> If the buffering filter sends everything down when it sees EOS, then
> we can't mix output from more than one request in a single network
> write.  That is what I was trying to point out above.  

Sure it can.  The buffering filter doesn't send anything to the network,
it just sends it to the next filter.  Look, the stack looks like:

buffer       <--  data sitting here

buffer gets an EOS bucket.  The data is sent to the chunk filter.  Here
the chunking data gets added.  Then it is passed to the core filter.  Now,
the core filter looks at how much data it has and determines that it isn't
worth sending yet, so it wants to save that data aside.  But, we have an
EOS, so we save the data to the bucket brigade that lives in the conn_rec
structure.  This works regardless of what filters are in the stack.

> > Simplicity.  Have you ever tried to modify BUFF or add a feature to
> > it?  The simple fact that we have already found five separate functions in
> > BUFF is the reason for splitting it all out.  It's the Unix philosphy of
> > doing one thing and doing it well.  If BUFF is split into five filters,
> > then they are much easier to fix, and much easier to add features to.
> This doesn't address my question.  (And I *have* worked in BUFF (but
> I'm not interested in the philosophical issues here, just in what new
> capability we will gain.))  I'm starting to think that we gain no new
> capability but instead we might be able to simplify the code.  Is that
> the case?

Yes, that is the case.  We make the code much easier to read and
understand.  We also reduce the chance for bugs in a bunch of code that
not many people understand.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message