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:
I have PROVEN beyond a shadow of a doubt that IIS can't handle multiple simultaneous connections to ANY CGI !!!! It's not the fault of PHP.EXE I've compiled the C code that's listed below and put it in C:\Inetpub\Scripts. If you would like a copy of the compiled exe drop me a line. For the sake of simplicity, this program is designed to be initially called with no parameters as in http://localhost/Scripts/breakiis.exe Also, for simplicity, I don't bother following the conventional name=value&name=value format of the URL string parameters but simply pass a number. This code is perfectly safe in that it will start the count at 1 if no parms are passed and if a QUERY_STRING that is non-numeric is passed, atof will return 0.0 so that is also safe. This program fully complies with the rules of CGI programming via the GET method in that it receives the URL string parameters via QUERY_STRING and sends back output via cout with a valid header. You will see that running one instance of this in the browser will work fine. Run multiple instances and you will break IIS. This program is designed to do nothing more than prove that there is a flaw in the way that IIS handles CGI processes and that the bug is in fact with IIS and not PHP. You *CANNOT* break Apache with multiple instances of this CGI code: ______________________________________________________ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> char *data; double count; int main(void) { data = getenv("QUERY_STRING"); if(data == NULL) count=1; else count = atof(data); printf("Content-Type:text/html\n\n"); printf("Loading page with value %f\n",floor(count)); count++; printf("<script>location.href='breakiis.exe?%f'</script>",count); return 0; } _______________________________________________________ I have launched yet another campaign to try and get Microsoft to fix this problem but honestly I think we'd have better luck just working out the bugs in php4isapi.dll. Maybe in the year 2025 Microsoft will get around to fixing this problem. Ottawa Previous Comments: ------------------------------------------------------------------------ [2003-03-17 17:49:27] ottawasixtyseven at hotmail dot com 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 ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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
