httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: Filtered I/O ... again. :-)
Date Wed, 31 May 2000 22:00:53 GMT
> From: rbb@covalent.net
> 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 | 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