httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Filtered I/O ... again. :-)
Date Wed, 31 May 2000 22:04:15 GMT
hehe... you really ought to read the incoming mail before sending a
response :-)

Everything you said is Goodness. I suggested the same thing, and Ryan
agrees with both of us.


On Wed, 31 May 2000, Jeff Trawick wrote:

> > From:
> > Date: Wed, 31 May 2000 14:41:43 -0700 (PDT)
> ...
> > Let's just add a bit to your example:  (Assume the SSI text is coming from
> > a CGI because then this all makes sense)
> > 
> > > Call 1: 
> > >   mod_include passes the first part of its input (up through the partial
> > >   SSI tag) to the next filter
> > > 
> > >   mod_include holds onto the partial SSI tag
> > > 
> > >   mod_include tells its caller that it processed all input data
> > 
> > Insert a SIG_PIPE here because the CGI died unexpectedly.  Ignore the rest
> > of your example because it never actually got sent due to a CGI
> > programming error.
> > 
> > The request_processing code doesn't know that mod_include is holding onto
> > some of the data waiting to process it.  The mod_include filter never gets
> > re-called, the data never gets freed from where mod_include stored it
> > temporarily.  A small flag says I need to be called at least one more time
> > so I can be flushed.
> > 
> > Ryan
> Isn't this covered by the statement "mod_include needs to be able to
> signal an error if the filter is removed but he is still waiting for
> the rest of an SSI tag." ?  Why would mod_include want to flush out
> the held data?  It is just yet another indicator that something went
> wrong.  
> I think a filter needs to be able to provide a routine to be called at
> the end to allow it to signal an error, but when would it need to
> flush data?  Presumably it is holding data waiting for more to come,
> and if more never comes then we have an error to report, not data to
> flush.
> (Counterexample: a module replaces any sequence of XXXXX with YYYYY.
> If it gets to the end of the input and has receive only XXXX, it
> should write XXXX once it knows its at the end.  O.k., I see the need
> to flush.)
> Maybe instead of having a filter set an indicator stating that it
> needs to be flushed, at the end of input we call the filters again with
> 0 bytes to write.  If a filter in the chain has data to flush, it
> knows to flush it now because nbytes==0.  It then flushes its data by
> calling the next filter with nbytes!= 0 but it then calls the next
> filter with nbytes==0 so that it can then flush.
> (This suggestion is because I wonder how much code is going to have to
> keep up with which filter needs to be called again to flush.  It seems
> simpler for a filter writer to do special processing for nbytes==0
> than to keep track of which module has data to flush.  I dunno...)
> -- 
> Jeff Trawick | | PGP public key at web site:
>           Born in Roswell... married an alien...

Greg Stein,

View raw message