install.txt

php5.0原代码

ftype PHPScript=c:\php\php.exe %1 %*

     * In the Netscape Enterprise Administration Server create a dummy
       shellcgi directory and remove it just after (this step creates 5
       important lines in obj.conf and allow the web server to handle
       shellcgi scripts).
     * In the Netscape Enterprise Administration Server create a new mime
       type (Category: type, Content-Type: magnus-internal/shellcgi, File
       Suffix:php).
     * Do it for each web server instance you want PHP to run

   More details about setting up PHP as a CGI executable can be found
   here: http://benoit.noss.free.fr/php/install-php.html
     _________________________________________________________________

NSAPI setup on Sun, iPlanet and Netscape servers

   To install PHP with NSAPI, do the following:

     * Copy php4ts.dll to your systemroot (the directory where you
       installed Windows)
     * Make a file association from the command line. Type the following
       two lines:

assoc .php=PHPScript
ftype PHPScript=c:\php\php.exe %1 %*

     * In the Netscape Enterprise Administration Server create a new mime
       type (Category: type, Content-Type: magnus-internal/x-httpd-php,
       File Suffix: php).
     * Edit magnus.conf (for servers >= 6) or obj.conf (for servers < 6)
       and add the following: You should place the lines after mime types
       init.

Init fn="load-modules" funcs="php4_init,php4_execute,php4_auth_trans" shlib="c:
/php/sapi/php4nsapi.dll"
Init fn="php4_init" LateInit="yes" errorString="Failed to initialise PHP!" [php
_ini="c:/path/to/php.ini"]

       (PHP >= 4.3.3) The php_ini parameter is optional but with it you
       can place your php.ini in your webserver config directory.
     * Configure the default object in obj.conf (for virtual server
       classes [Sun Web Server 6.0+] in their vserver.obj.conf): In the
       <Object name="default"> section, place this line necessarily after
       all 'ObjectType' and before all 'AddLog' lines:

Service fn="php4_execute" type="magnus-internal/x-httpd-php" [inikey=value inik
ey=value ...]

       (PHP >= 4.3.3) As additional parameters you can add some special
       php.ini-values, for example you can set a
       docroot="/path/to/docroot" specific to the context php4_execute is
       called. For boolean ini-keys please use 0/1 as value, not
       "On","Off",... (this will not work correctly), e.g.
       zlib.output_compression=1 instead of zlib.output_compression="On"
     * This is only needed if you want to configure a directory that only
       consists of PHP scripts (same like a cgi-bin directory):

<Object name="x-httpd-php">
ObjectType fn="force-type" type="magnus-internal/x-httpd-php"
Service fn=php4_execute [inikey=value inikey=value ...]
</Object>

       After that you can configure a directory in the Administration
       server and assign it the style x-httpd-php. All files in it will
       get executed as PHP. This is nice to hide PHP usage by renaming
       files to .html.
     * Restart your web service and apply changes
     * Do it for each web server instance you want PHP to run

     Note: More details about setting up PHP as an NSAPI filter can be
     found here: http://benoit.noss.free.fr/php/install-php4.html

     Note: The stacksize that PHP uses depends on the configuration of
     the webserver. If you get crashes with very large PHP scripts, it
     is recommended to raise it with the Admin Server (in the section
     "MAGNUS EDITOR").
     _________________________________________________________________

CGI environment and recommended modifications in php.ini

   Important when writing PHP scripts is the fact that Sun JSWS/Sun ONE
   WS/iPlanet/Netscape is a multithreaded web server. Because of that all
   requests are running in the same process space (the space of the
   webserver itself) and this space has only one environment. If you want
   to get CGI variables like PATH_INFO, HTTP_HOST etc. it is not the
   correct way to try this in the old PHP 3.x way with getenv() or a
   similar way (register globals to environment, $_ENV). You would only
   get the environment of the running webserver without any valid CGI
   variables!

     Note: Why are there (invalid) CGI variables in the environment?

     Answer: This is because you started the webserver process from the
     admin server which runs the startup script of the webserver, you
     wanted to start, as a CGI script (a CGI script inside of the admin
     server!). This is why the environment of the started webserver has
     some CGI environment variables in it. You can test this by starting
     the webserver not from the administration server. Use the command
     line as root user and start it manually - you will see there are no
     CGI-like environment variables.

   Simply change your scripts to get CGI variables in the correct way for
   PHP 4.x by using the superglobal $_SERVER. If you have older scripts
   which use $HTTP_HOST, etc., you should turn on register_globals in
   php.ini and change the variable order too (important: remove "E" from
   it, because you do not need the environment here):
variables_order = "GPCS"
register_globals = On
     _________________________________________________________________

Special use for error pages or self-made directory listings (PHP >= 4.3.3)

   You can use PHP to generate the error pages for "404 Not Found" or
   similar. Add the following line to the object in obj.conf for every
   error page you want to overwrite:
Error fn="php4_execute" code=XXX script="/path/to/script.php" [inikey=value ini
key=value...]

   where XXX is the HTTP error code. Please delete any other Error
   directives which could interfere with yours. If you want to place a
   page for all errors that could exist, leave the code parameter out.
   Your script can get the HTTP status code with $_SERVER['ERROR_TYPE'].

   Another possibility is to generate self-made directory listings. Just
   create a PHP script which displays a directory listing and replace the
   corresponding default Service line for
   type="magnus-internal/directory" in obj.conf with the following:
Service fn="php4_execute" type="magnus-internal/directory" script="/path/to/scr
ipt.php" [inikey=value inikey=value...]

   For both error and directory listing pages the original URI and
   translated URI are in the variables $_SERVER['PATH_INFO'] and
   $_SERVER['PATH_TRANSLATED'].
     _________________________________________________________________

Note about nsapi_virtual() and subrequests (PHP >= 4.3.3)

   The NSAPI module now supports the nsapi_virtual() function (alias:
   virtual()) to make subrequests on the webserver and insert the result
   in the webpage. The problem is, that this function uses some
   undocumented features from the NSAPI library.

   Under Unix this is not a problem, because the module automatically
   looks for the needed functions and uses them if available. If not,
   nsapi_virtual() is disabled.

   Under Windows limitations in the DLL handling need the use of a
   automatic detection of the most recent ns-httpdXX.dll file. This is
   tested for servers till version 6.1. If a newer version of the Sun
   server is used, the detection fails and nsapi_virtual() is disabled.

   If this is the case, try the following: Add the following parameter to
   php4_init in magnus.conf/obj.conf:
   Init fn=php4_init ... server_lib="ns-httpdXX.dll"

   where XX is the correct DLL version number. To get it, look in the
   server-root for the correct DLL name. The DLL with the biggest
   filesize is the right one.

   You can check the status by using the phpinfo() function.

     Note: But be warned: Support for nsapi_virtual() is EXPERIMENTAL!!!
     _________________________________________________________________

OmniHTTPd Server

   This section contains notes and hints specific to OmniHTTPd on
   Windows.

     Note: You should read the manual installation steps first!

   Warning

   By using the CGI setup, your server is open to several possible
   attacks. Please read our CGI security section to learn how to defend
   yourself from those attacks.

   You need to complete the following steps to make PHP work with
   OmniHTTPd. This is a CGI executable setup. SAPI is supported by
   OmniHTTPd, but some tests have shown that it is not so stable to use
   PHP as an ISAPI module.

     Important for CGI users: Read the faq on cgi.force_redirect for
     important details. This directive needs to be set to 0.

    1. Install OmniHTTPd server.
    2. Right click on the blue OmniHTTPd icon in the system tray and
       select Properties
    3. Click on Web Server Global Settings
    4. On the 'External' tab, enter: virtual = .php | actual =
       c:\php\php.exe (use php-cgi.exe if installing PHP 5), and use the
       Add button.
    5. On the Mime tab, enter: virtual = wwwserver/stdcgi | actual =
       .php, and use the Add button.
    6. Click OK

   Repeat steps 2 - 6 for each extension you want to associate with PHP.

     Note: Some OmniHTTPd packages come with built in PHP support. You
     can choose at setup time to do a custom setup, and uncheck the PHP
     component. We recommend you to use the latest PHP binaries. Some
     OmniHTTPd servers come with PHP 4 beta distributions, so you should
     choose not to set up the built in support, but install your own. If
     the server is already on your machine, use the Replace button in
     Step 4 and 5 to set the new, correct information.
     _________________________________________________________________

Sambar Server on Microsoft Windows

   This section contains notes and hints specific to the Sambar Server
   for Windows.

     Note: You should read the manual installation steps first!

   This list describes how to set up the ISAPI module to work with the
   Sambar server on Windows.

     * Find the file called mappings.ini (in the config directory) in the
       Sambar install directory.
     * Open mappings.ini and add the following line under [ISAPI]:

   Example 2-7. ISAPI configuration of Sambar
#for PHP 4
*.php = c:\php\php4isapi.dll

#for PHP 5
*.php = c:\php\php5isapi.dll

       (This line assumes that PHP was installed in c:\php.)
     * Now restart the Sambar server for the changes to take effect.
     _________________________________________________________________

Xitami on Microsoft Windows

   This section contains notes and hints specific to Xitami on Windows.

     Note: You should read the manual installation steps first!

   This list describes how to set up the PHP CGI binary to work with
   Xitami on Windows.

     Important for CGI users: Read the faq on cgi.force_redirect for
     important details. This directive needs to be set to 0. If you want
     to use $_SERVER['PHP_SELF'] you have to enable the cgi.fix_pathinfo
     directive.

   Warning

   By using the CGI setup, your server is open to several possible
   attacks. Please read our CGI security section to learn how to defend
   yourself from those attacks.

     * Make sure the webserver is running, and point your browser to
       xitamis admin console (usually http://127.0.0.1/admin), and click
       on Configuration.
     * Navigate to the Filters, and put the extension which PHP should
       parse (i.e. .php) into the field File extensions (.xxx).
     * In Filter command or script put the path and name of your PHP CGI
       executable i.e. C:\php\php.exe for PHP 4, or C:\php\php-cgi.exe
       for PHP 5.
     * Press the 'Save' icon.
     * Restart the server to reflect changes.
     _________________________________________________________________

Installation of extensions on Windows

   After installing PHP and a webserver on Windows, you will probably
   want to install some extensions for added functionality. You can
   choose which extensions you would like to load when PHP starts by
   modifying your php.ini. You can also load a module dynamically in your
   script using dl().

   The DLLs for PHP extensions are prefixed with php_.

     Note: In PHP 4.3.1 BCMath, Calendar, COM, Ctype, FTP, MySQL, ODBC,
     Overload, PCRE, Session, Tokenizer, WDDX, XML and Zlib support is
     built in. You don't need to load any additional extensions in order
     to use these functions. See your distributions README.txt or
     install.txt or this table for a list of built in modules.

   The default location PHP searches for extensions is c:\php4\extensions
   in PHP 4 and c:\php5 in PHP 5. To change this setting to reflect your
   setup of PHP edit your php.ini file:

     * You will need to change the extension_dir setting to point to the
       directory where your extensions lives, or where you have placed
       your php_*.dll files. Please do not forget the last backslash. For
       example: