ID: 9852
Comment by: ottawasixtyseven at hotmail dot com
Reported By: ron dot baldwin at sourceprose dot com
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
Lewid,
Have you considered trying php4isapi.dll? PHP admits that it's *STILL*
not production quality (how many years has it been ???) but some
people have had great success with it.
I think I may have finally figured out why PHP.EXE spits out those CGI
errors. And why on faster machines it happens more often ... IT'S NOT
THREAD-SAFE !!!
I don't know why this didn't dawn on me earlier. It makes total sense.
The problem occurs when IIS tries to make simultaneous calls to
PHP.EXE. With php4isapi.dll, instead of loading PHP.EXE for each
request, ISAPI uses the thread-safe DLL that's loaded only once. Apache
must handle CGI differently because you NEVER get the CGI error.
We can't use php4isapi.dll with our application because for some reason
it blows up all over the place with server 500 errors. We continue to
pray that the PHP gods will deliver us a rock solid php4isapi.dll.
Until then we deal with the CGI errors and blame it on Bill.
Again, for some reason changing your Performance Options to either
Background services or Applications seems to really make a difference.
Even with this option change frankielam has proven that when opening
multiple instances of his script (see above doit.php) you can generate
CGI errors at will. Try this at home and impress your friends :-)
Please let us know if running php4isapi.dll works for you.
Ottawa
Previous Comments:
------------------------------------------------------------------------
[2003-03-17 07:15:53] lewid at nc dot rr dot com
I am at a loss here - I am a developer for a large company and do not
have a choice as to which web platform I can use - IIS is the tool I
have to work with.
I have been using php on IIS but this growing percentage of CGI errors
on my applications is forcing me to consider using a different
application server, as it does not appear at this time that it will be
resolvable.
Is there ANY hope, or should I just switch to a different application
server, as I do not feel that it is acceptable for my applications to
recieve a significant % of errors.
If anyone has any suggestions please email me - ps - switching to an
open source web server is not an option I can entertain at this time :(
------------------------------------------------------------------------
[2003-03-14 18:52:30] [EMAIL PROTECTED]
Friendly suggestion: Stick to OpenSource solutions. :)
------------------------------------------------------------------------
[2003-03-14 12:53:39] ottawasixtyseven at hotmail dot com
frankielam,
You've hit the nail on the head. It's a problem with IIS. This DOES NOT
HAPPEN *EVER* with Apache. IIS is not able to handle multiple
simultaneous calls to php.exe.
The question is now ... how the hell do we get Micro$haft to fix this?
They are about as responsive to bugs likes this ... as a brick wall! I
wish this was a PHP error because the lads at PHP are usually quite
responsive to bugs.
Anybody have any suggestions on how to get Bill to listen? I've tried
calling support, posting messages, no luck. We have switched all our
servers over to RedHat and the ones that MUST remain Windoze are
running Apache Web server.
It still should be noted that changing the Performance options can
greatly reduce the occurence of the CGI error. Unfortunately, it does
not eliminate it.
Ottawa
------------------------------------------------------------------------
[2003-03-05 20:32:01] frankielam at ucr dot com dot hk
I can reproduce the error with the php script below(a simple script
that do nothing but keeps refreshing itself with a different value of
parameter passed into it as GET, REMEMBER to open serveral instances to
run it.). IMHO, this is not a database problem(neither mysql nor
mssql), and this might be a problem that IIS cannot handle sucha high
frequent call to `php.exe', and it does assume that php.exe returns
nothing!! (Am I right? :-D)
doit.php
8<-----------------------------------------------
<?
echo "<html><head><title>testing</title>";
if (isset($_GET["times"]))
$times = ($_GET["times"]) + 1;
else
$times = 0;
//SEE??? even i comment the statement out, infamous cgi error occurs,
STILL!
//$conn = mssql_connect('127.0.0.1', 'sa', '') or die("couldn't
connect");
echo "<meta http-equiv=\"Refresh\" content=\"0; URL=doit.php?times=" .
$times . "\"></head></html>";
echo "Trying CGI";
echo "<BR>$times";
//header("doit.php");
?>
8<-----------------------------------------------
My config.:
Windows 2000 Advanced Server with SP3
PHP 4.3.1 / 4.2.3 (both tested to have CGI problem)
MSSQL Server 2000
------------------------------------------------------------------------
[2003-03-03 17:23:06] gkasten at filnet dot fr
http://support.microsoft.com/default.aspx?scid=kb;en-us;151825
http://bugs.php.net/bug.php?id=9852
Hello bugbrowsers (same comment as 12700, but this thread is better),
I tried too unsuccessfully : -background perf -mdac -admin and various
other commented things above, on IIS w2kSrv & NT4 , php 4.*<=4.3.1 :-(
I had the problem on /phpmyadmin subdir, protected by ACLs.
And only with far-tracerouted client machines.
* I SUCCEEDED with unchecking "directory-security /
allow-anonymous-access" (which is theorically useless because there is
no IUSR_* in the acls of php pages below).
I hope it can help desperate hostmasters, and php-dev-community to
track this @#%! bug.
Guy Kastenbaum - Paris
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/9852
--
Edit this bug report at http://bugs.php.net/?id=9852&edit=1
