3. PHP SAPI modules

3.1 ISAPI module

The developers of PHP support several SAPI (Server API) modules for PHP (Apache, NSAPI, ISAPI, ...). On Win32 systems use the source distribution of PHP to build an PHP ISAPI module or take it from the Win32 binary distribution. You can use the ISAPI module (which is internally both, an ISAPI filter and an extension) with the ISAPI interface of Pi規eb within Win32 environments, but this has not been tested yet.

3.2 SAPI module for Pi3Web

Based on the SAPI interface there's a PHP4 wrapper module as an integrated PHP4 interface for Pi規eb. It is available in Pi規eb version 2.0.0 or greater or in PHP4 source code as well as in binary distributions for Win32. Follow the instructions in the README file in the ./Source/PHP4 folder to build Pi規eb with PHP4 support. PHP 4 source code has to be configured with

configure --with-pi3web
make

in order to build the Pi3Web sources. There're some path dependencies, which require to unpack the complete PHP4 source tree into the folder ./Pi3Web/Source/PHP4.

There're also some additions, which have to be made in the configuration. Don't forget to include:

include ../Conf/PHP4.cnf

For Win32 binary distributions of Pi3Web the PHP4 support is part of the default configuration, i.e. you don't need to perform any configuration changes to get PHP working. For Pi3Web running with a custom configuration file or running on Linux and other 'UX systems the configuration need to be extended in the following way. Similar to the CGI variant, the Start object has to be extended in order to add the appropriate mapping:

<Object>
        Name Start
        Class FlexibleHandlerClass
        ...
        Mapping Condition="&or(&regexp('*.php',$U),&regexp('*.php',$f))" PHP4Mapper \
From="/" To="WebRoot\"
        ...
</Object>

Now add a new PathMapper object called 'PHP4Mapper':

<Object>
        Name PHP4Mapper
        Class PathMapperClass
        PathInfo Yes
        ...
        Action "&dbreplace(response,string,ObjectMap,PHP4)"
        ...
</Object>

A new FlexibleHandler object is created in order to handle all request phases correctly:

<Object>
        Name DoPHP4
        Class FlexibleHandlerClass
        Condition "&cmp(&dblookup(response,string,ObjectMap),PHP4Scripts)"
        CheckPath RefuseFileByMask AllowFileMask="EFD" RefuseStatus=404
        CheckPath RefuseFileByMask AllowFileMask="F" RefuseStatus=403
        CheckPath ReturnCode ReturnCode=COMPLETED
        CheckAccess AccessByFile RequirePermissions="X"
        CheckType ReturnCode ReturnCode=COMPLETED
        Handle PHP4
</Object>

Finally this new handler has to be inserted into the handler chain, which is configured within the HTTP dispatcher object, e.g.:

<Object>
        Name HTTPLogicObject
        Class HTTPDispatcherClass
        ...
       Handlers Start Scripts DoPHP4 Default
        ...
</Object>

Instead of the Mapping condition with a specific PathMapper and a FlexibleHandler you can also use a MIME type mapping and then call the PHP4 handler directly from the Default handler:

<Object>
        Name HTTPLogicObject
        Class HTTPDispatcherClass
        ...
       AddMIMEEntry "php    internal/x-server-parsed-php"
        ...
</Object>
<Object>
        Name Default
        Class FlexibleHandlerClass
        ...
        Handle Condition="&cmp($c,internal/x-server-parsed-php)" PHP4
        ...
</Object>

With both variants you can place your PHP scripts in arbitrary directories inside your WebRoot directory. But if the PATH_INFO variable is needed and you are using the second variant, you have to switch on the 'PathInfo' parameter either for the PathMapper class (in HTTP.cnf) or specific for the default mapping of '/' to the 'WebRoot' folder (Mapping PathMapper From="/" To="WebRoot/" PathInfo="Yes") . The configuration file generated by the Win32 administration client uses the second variant because it doesn't need an extra processing during the 'Mapping' phase, i.e. generates less overhead during request processing.