Re: FastCGI & nph ?

Mark Brown (mbrown@openmarket.com)
Thu, 12 Sep 1996 11:24:00 -0400

Message-Id: <199609121524.LAA12451@breckenridge.openmarket.com>
To: fastcgi-developers@openmarket.com
Subject: Re: FastCGI & nph ? 
In-Reply-To: <3235B4B4.1CFB@nineco.com> 
Date: Thu, 12 Sep 1996 11:24:00 -0400
From: Mark Brown <mbrown@openmarket.com>


Michael Colena asked:

    Is it possible for an FCGI app to respond directly to the client, ala
    nonparsed headers?  How or why not?  Thanks.

To elaborate on Bill Snapper's reply:

My understanding is that the original motivation for nph scripts was
to work around limitations in CGI.  These limitations were removed in
the current version, CGI/1.1.

The remaining motivation for nph scripts was to work around a buffering
problem that existed in some Web servers.  Some servers buffered CGI
script output indefinitely, only guaranteeing to flush script output
when the CGI output is complete.  This behavior did not allow "server
push" applications to function correctly.  But modern Web servers
don't have the buffering problem.

In modern Web servers there is no question of a script "responding
directly to the client," because the Web server may need to perform
transport-level processing on the script output.  This is the case
with SSL connections, and it is also the case when the application
speaks FastCGI.  So in all modern Web servers a script
responds to the Web server, and the Web server responds to the client.

In summary, there no longer appears to be a need for the nph
feature in CGI.  That's why the FastCGI specification does not
support nph.  If you think there's still a need for nph,
please explain why.

    --mark