Plumbing of Fast CGI Streams

Mark Brown (mbrown@openmarket.com)
Wed, 03 Jul 1996 12:50:13 -0400

Message-Id: <199607031650.MAA23342@breckenridge.openmarket.com>
To: fastcgi-developers@openmarket.com
Subject: Plumbing of Fast CGI Streams 
In-Reply-To: Your message of "Tue, 02 Jul 1996 09:38:30 EDT."
             <31D92656.66E3@digicool.com> 
Date: Wed, 03 Jul 1996 12:50:13 -0400
From: Mark Brown <mbrown@openmarket.com>


Jim Fulton asked:

    Fast CGI applications read and write file(-ish) streams.  Are
    these streams plumbed through to the browsers?  (This would be
    advantageous for some apps, as the browser could display partial
    results while computation proceeds.) Or do web servers buffer the
    stream behavior away?

A FastCGI app talks to a Web server, which talks back to the
browser.  Just like regular (server-parsed-header) CGI.

The Web server does not buffer output indefinitely; it is quite
aggressive about pushing data received from the FastCGI app
out to the browser.  Server push should work just fine with FastCGI
(I admit I haven't tried it).

The FastCGI application library also performs buffering, so a
server push app would need to call fflush(stdout) in order to make
the output move to the Web server.

    Can a slow browser (or connection with same) cause a
    single-threaded Fast CGI application to block on input or output,
    preventing the application from servicing other requests?  Or is
    all input gathered from the browser by the (mult-thread/process)
    server before sending the request to the app and all output from
    the app gathered by the server before sending to the browser?

The server has a reasonably large per-connection buffer (16 K bytes in
the case of the Open Market Secure WebServer) so the app would have to
write quite a bit in order to block.  But if the buffer fills the
application will block.  In the future we'd like to make the buffers
expand on demand in order to prevent the application from blocking on
output.

There typically isn't much input so applicatin blocking on input is
quite rare.  A large POST could do it though.  The server does *not*
pre-read CONTENT_LENGTH bytes before connecting to the app.

An application could accept multiple connections in order to avoid
blocking, but not using the current app lib.

    --mark