httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: eek. poor chunking behavior.
Date Tue, 12 Sep 2000 14:13:04 GMT
rbb@covalent.net writes:

> > One issue with such a buffering filter is that buffering is
> > connection-oriented but chunking is request-oriented.
> > 
> > Buffering is connection-oriented in that (for pipelined responses) we
> > want the ability to send output for multiple responses in one network
> > write.  (Of course, we'd flush any final output from one request if
> > the next request has not yet arrived.)
> > 
> > Chunking is request-oriented in that a chunk can't contain content
> > from more than one request.
> > 
> > When buffering is above chunking, some special bucket (sort of like
> > EOS but not quite the same) would be required to tell the chunk filter
> > where the output of one request ends and where the output of the next
> > request begins.
> 
> 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.  

> > Hmmm... Thus far we are talking about five filters to replace buff:
> > 
> >   content character set translation filter
> >   buffering filter
> >   chunking filter
> >   core filter
> >   implementation character set filter
> > 
> > What is the added capability from replacing buff?  Being able to drop
> > in alternative transport encodings?
> 
> 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?

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message