Executing PHP scripts with OSU web server.

[jonesd]

I haven't seriously looked at PHP since 2007 (version 4.4.7), but a thread on comp.os.vms nudged me to take another look since VSI has a PHP kit. The SAPI module interface doesn't appear to have changed too much so it wasn't that much work to get the old custom interpreter to build against the 8.0.10 library (PHP$SHR). The reason for the custom interpreter is that it can build the CGI environment directly as PHP variables without the limitations inherent with mapping them to DCL symbols and/or logical names (cgi_symbols.exe).

The attached zip file has 3 files:

• script_code/php_cgilib.c (source file for interpreter)
• script_code/php.opt (linker options file to link php_cgilib.obj with cgilib and PHP$SHR)
• script_code/descrip.mms (updated MMS file to build php.exe and copy to [-.system])

Placing this custom php.exe in www_system should make WWWEXEC.COM automatically use it to process .php files in the exec directory (e.g. /htbin/phpinfo.php). If you want to be more expansive, place php.exe itself in the exec directory (www_root:[bin]) and any .php file accessible to the server can be executed (e.g. /htbin/php.exe/~smith/personal.php).

[arne_v]

You have tested with VSI PHP.

Will it work with Mark Berryman PHP?

VSI PHP does not come with MySQL support, but Mark Berryman PHP does, so the latter is more interesting.

[jonesd]

You have tested with VSI PHP.

Will it work with Mark Berryman PHP?

VSI PHP does not come with MySQL support, but Mark Berryman PHP does, so the latter is more interesting.

The 8.1.23 kit at https://theberrymans.com/php_kits/ does not include the header files used when building phpshr.exe.
A quick test using the 8.0 header files from the VSI kit still seems to work, though you have to remove the "#pragma names as_is" line from php_cgilib.c as phpshr.exe has uppercase symbols and php$shr.exe is case-preserved.

[arne_v]

Interesting.

I will have to give it a try.

OSU was my favorite web server for many years.

Added in 9 hours 44 minutes 41 seconds:
Just did some testing.
.
First a note: the PHP kit builds fine on x86-64 with PHP 8.1 - it does not build on Alpha with PHP 5.6 (I don't know if that is worth pursuing as 5.6 is utterly obsolete, but I assume the kit worked with PHP 5 originally).

PHP works fine. Based on my very limited test.

Static content performance is super. But PHP performance is not super. No surprise as it is CGI based.

So question one: how difficult would it be to create an MST for PHP?

php_cgilib.c actually list 4 ways to use it. You recommend #1 for security reasons. But #3 is the one used by practically all other web servers.

So question two: is the discourage of #3 just general "better safe than sorry" or are there some potential issues for OSU that does not apply to the other web servers using that method.

Added in 2 minutes 33 seconds:
And thank you for you great work with OSU httpd over 30 years!!

[jonesd]

Just did some testing.
.
First a note: the PHP kit builds fine on x86-64 with PHP 8.1 - it does not build on Alpha with PHP 5.6 (I don't know if that is worth pursuing as 5.6 is utterly obsolete, but I assume the kit worked with PHP 5 originally).

Originally it was 4.7, PHP 5 was out but I didn't feel like getting it to work on VMS.

PHP works fine. Based on my very limited test.

Static content performance is super. But PHP performance is not super. No surprise as it is CGI based.

So question one: how difficult would it be to create an MST for PHP?

The main issue is memory concerns. You have to size the stack allocation for the threadpool you'd use to service PHP and I don't have a feel for how much stack the zend engine uses. You'd also have to review the request cleanup to make sure there are no memory leaks or other residue from previous requests.

php_cgilib.c actually list 4 ways to use it. You recommend #1 for security reasons. But #3 is the one used by practically all other web servers.

So question two: is the discourage of #3 just general "better safe than sorry" or are there some potential issues for OSU that does not apply to the other web servers using that method.

By default, scripts run as the same username as the web server itself. Too many administrators just find it easier to 'fix' a configuration issue by giving it privileges than figuring out the safe solution. Unix servers have better one-way mechanisms for de-privileging their worker processes.

[arne_v]

PHP works fine. Based on my very limited test.

Static content performance is super. But PHP performance is not super. No surprise as it is CGI based.

So question one: how difficult would it be to create an MST for PHP?

The main issue is memory concerns. You have to size the stack allocation for the threadpool you'd use to service PHP and I don't have a feel for how much stack the zend engine uses. You'd also have to review the request cleanup to make sure there are no memory leaks or other residue from previous requests.

I don't know how much stack per thread either. I would start with 1 MB and double until it works.

I will volunteer to test.

Does a 2 MB thread stack cost anything or is it only the N actual 8 KB pages used that cost?

Are there a constraint:

number of threads * thread stack size + k <= size of P1 space

?

I am less concerned about the risk of memory leaks. There must be hundreds of thousands of users running Apache with a multi-threaded MPM and mod_php.

[arne_v]

I am less concerned about the risk of memory leaks. There must be hundreds of thousands of users running Apache with a multi-threaded MPM and mod_php.

Note that just because php are built thread safe on Windows (everything PHP on Windows has 4 builds: x86/x64 and nts/ts), then that does not mean that PHP on VMS are thread safe or that it would be trivial to do so. But I am optimistic - my impression is that the non thread safe preference is more because of concerns about bad extensions and a few less important edge cases (example: setlocale in one thread impacting other threads).