httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject How will CGIs be handled using filters?
Date Wed, 23 Aug 2000 19:10:41 GMT
The Apache 1.3 CGI handler calls ap_send_fb() to direct CGI output to the network.
ap_send_fb() reads data from a pipe (through BUFF) and writes it (through an output BUFF)
to the network.  By default, ap_send_fb() does non-blocking ap_bread()s.  If a ap_bread()
returns EWOULDBLOCK (or EAGAIN, whatever...), the output BUFF is flushed to the network,
then the next ap_bread() is set to be blocking.  We MUST replicate this behaviour when
using filters. It is not clear to me how this will work.

Our filter structure may look something like this:

CGI content generator does something like this...
    bb = ap_create_brigade()
    while (1) {
               b = ap_create_bucket_pipe()
               ap_pass_brigade(bb, b)
    }

The filter stack should look something like this:
F1 - chunked encoding filter
F2 - core filter

In this case, the chunking filter is calling the read method of a pipe bucket. It needs to
loop on this read until the CGI is done. This read needs to be non-blocking by default. If
a read returns EWOULDBLOCK/EAGAIN, then we need a way to flush the remaining data out the
lower level filters. Notice the chunking filter is controlling the blocking/non-blocking
behavious of the pipe.

Now consider this case... We add a translation phase ..

CGI Generator...
F1 - translation
F2 - chunking
F3 - core

Which filter controls the blocking attribute of the pipe? Does this behaviour need to be
built into the translation filter? I think not. In Apache 1.3, this decision is made
outside or above the translation and i/o layers. I don't see how we can have the same
control using bucket brigades through filters, not cleanly anyway.

Bill


Mime
View raw message