Date: Tue, 30 Sep 1997 15:21:37 -0600 (MDT)
From: Marc Slemko <marcs@worldgate.com>
To: new-httpd@apache.org
Subject: Re: CHANGES entry on nph- CGIs
In-Reply-To: <199709302108.OAA03678@gabber.c2.net>
Message-ID: <Pine.BSF.3.95q.970930151504.29966G-100000@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Tue, 30 Sep 1997, Dean Gaudet wrote:

> >      the output before sending.  The programmer can still use "nph-"
> >      CGIs, which provide a direct socket to the client without
> >      Apache getting involved, but they are no longer necessary for
> >      many applications.  "nph-" CGIs are not fully compatible with
> 
> They're not at all compatible with HTTP/1.1 unless they implement
> chunking. 

They are completely compatible with HTTP/1.1 without implementing chunking
iff clients aren't sending data to them with a PUT, etc.  Saying they are
not compatible implies that they will fall over horribly.  In reality,
they will only do so under certain conditions.  Nothing is preventing a
nph CGI from sending a non-chunked HTTP/1.1 response or a HTTP/1.0
response to a 1.1 request.  People just scare easily.

On Tue, 30 Sep 1997, sameer wrote:

> 	Actually, now nph CGI *is* compatible. nph stands for
> "non-parsed headers" -- it doesn't stand for "direct socket
> connection" -- Before the nph- meant you had a direct socket
> connection, which wasn't really the true meaning of nph. Now nph means
> that the headers are passed direct to the client, without being
> parsed.. I.e. non-parsed.

Erk.  That is bad.  That breaks something.  Well, it could just be the
current implementation.  Unbuffered CGIs aren't working well for me.  Not
well enough to get rid of nph == direct socket.  More when I have looked
at what is happening...

> 
> > I'm still not sure I like this:
> > 
> >   *) "nph-" CGIs were not compatible with HTTP/1.1 or SSL support because
> >      they were passed a socket that connected directly to the client.
> >      As such they would have to implement the transport level details
> >      such as encryption or chunking in order to work properly.
> >      This isn't part of the CGI spec so CGIs generally don't do this.
> >      The most common use of nph- CGIs is when the programmer wants an
> >      unbuffered connection to the client; regular CGIs have always been
> >      fully buffered.  Apache now provides an unbuffered connection to
> >      all CGIs.  Given that most CGIs are written in a language that by
> >      default does buffering (i.e. perl) this shouldn't have a detrimental
> >      effect on performance.  The programmer can still use nph- CGIs,
> >      and they're still responsible for sending valid HTTP/1.1 responses.
> >      [Dean Gaudet, Sameer Parekh, Roy Fielding]
> > 
> > It says nph- CGIs were not compatible.  They still are not compatible, so
> > were incorrectly implies it has changed.
> > 
> > The description of what the feature is should be at the start, not hidden
> > in the end.
> > 
> > How about changing it to:
> > 
> >   *) Apache now provides an effectively unbuffered connection for
> >      CGI scripts.  This means that data will be sent to the client
> >      almost as soon a the CGI outputs it; previous, Apache buffered
> >      the output before sending.  The programmer can still use "nph-"
> >      CGIs, which provide a direct socket to the client without
> >      Apache getting involved, but they are no longer necessary for
> >      many applications.  "nph-" CGIs are not fully compatible with
> >      HTTP/1.1 or SSL support because they are passed a socket that
> >      is connected directly to the client.  As such they would have to
> >      implement the transport level details such as encryption or
> >      chunking in order to work properly in certain situations.
> >      This isn't part of the CGI spec so CGIs generally don't do
> >      this; more importantly, they should not need to know such
> >      transport level details.  Given that most CGIs are written in
> >      a language that by default does buffering (e.g. perl) this
> >      shouldn't have a detrimental effect on performance.  [Dean
> >      Gaudet, Sameer Parekh, Roy Fielding]
> > 
> > 
> > 
> 
> 
> -- 
> Sameer Parekh					Voice:   510-986-8770
> President					FAX:     510-986-8777
> C2Net
> http://www.c2.net/				sameer@c2.net
>