httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: fork free
Date Mon, 24 Apr 1995 18:02:35 GMT
   From: Rob Hartill <>
   Date: Mon, 24 Apr 95 15:24:23 MDT

   Looking for a "nph" prefix is just plain ugly and almost impossible
   to switch to once you have popular URLs. A mime type based on the
   file extension would look better than a nph prefix, but it's just
   as bad when it comes to switching an existing URL to be a "nph" script.

MultiViews can be used to fudge this issue.  

   Now that we've sorted out the sleep 3/die problem, I think we can
   change the behaviour of script handling to the following...

    read the headers
    output headers
    if header contains some special directive, e.g. Httpd: full-speed-ahead
       send the document body using nph technology
       use existing setup.

Ummm...  I'm not *quite* sure I understand how this is supposed to work.

The two most important things about nph- these days seem to be that
the script doesn't get screwed up by buffering done by the server (for
Netscape-style "server push" animation), and for us, that a server
process doesn't have to watch the connection, meaning that the server
itself can go on to service another connection.  Both properties
require that the socket be passed to the script, so that the server
doesn't have to do further I/O, and can forget about it.  However,
that precludes anything like the server's usual processing of CGI

So, I'm not sure I see how the server is supposed to put off the
decision of whether or not to go the nph- route until after the script
is actually sending output --- to do that, it has to see the output,
which means the script can't be running under nph "rules of engagement".


View raw message