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:53:10 GMT
rbb@covalent.net writes:

> > > 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
> chunk
> core
> 
> 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.

So the core filter still needs to have buffering logic even when we
have a buffering filter?  If that is the case then perhaps, as
somebody (Tony?) mentioned last night, the relatively simple buffering
logic should be duplicated in the chunk filter and the core filter.

-- 
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