#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"

ID: 9852 Comment by: jitse dot groen at grib dot nl 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: Dear all, I'm probably not as experienced in PHP as all of you but I found a solution that *seems* to work fine for our sites. I base this on tests with doit.php by frankielam. I should also mention running iisreset once in a while decreased the number of CGI errors per day. It takes about 1-2 weeks for the bug to become noticable to us. It is present before that time but will not show that often. Changing performance to optimize for applications I really cannot consider. How can reducing the speed of our servers be a solution? A possible solution though: After increasing the paging file size (virtual memory) I cannot reproduce the bug however often I try. I'm not absolutely convinced that this will do the trick, but for now, it works. I would be anxious to hear your experiences with this solution. With kind regards, Jitse Groen, The Netherlands Previous Comments: ------------------------------------------------------------------------ [2003-03-21 07:31:33] lewid at nc dot rr dot com Thank you very much for all you comments, Ottawa67! I have implemented ISAPI using php4isapi.dll in our production environment now and it appears to work perfectly and has solved the problem we were having. I will contribute any bugs I encounter but so far it is working ... perfectly! ------------------------------------------------------------------------ [2003-03-20 17:10:36] ottawasixtyseven at hotmail dot com Lewid, php4isapi.dll works perfectly for some people. We are part of the unfortunate group that experiences lots of server 500 errors. Here is an excerpt from the latest PHP INSTALL text file: _________________________________________________ PHP 4 for Windows comes in two flavours - a CGI executable (php.exe), and several SAPI modules (for exapmle php4isapi.dll). The latter form is new to PHP 4, and provides significantly improved performance and some new functionality. However, please note that the SAPI modules are *NOT* yet considered to be production quality. In particular, with the ISAPI module, you are likely to encounter serious reliability problems especially on platforms older than W2K - you may witness a lot of server 500 errors and suffer from other server modules such as ASP also failing. You have been warned! The reason for this is that the PHP SAPI modules are using the thread-safe version of the PHP code, which is new to PHP 4, and has not yet been tested and pounded enough to be considered completely stable, and there are actually a few known bugs. On the other hand, some people have reported very good results with the SAPI modules, and there a few reports of problems with the Apache module version. In short - your mileage may vary; If you need absolute stability, trade the performance of the SAPI modules with the stability of the CGI executable. _________________________________________________ Hopefully you can be part of the increasing numbers that are actually able to give php4isapi.dll a good pounding. Please make sure to report any problems you have with it. Ottawa ------------------------------------------------------------------------ [2003-03-20 15:28:49] lewid at nc dot rr dot com What bugs are there in php4isapi.dll (referring to above comment)? I am using an isapi filter pointing to php4isapi.dll and it seems to have fixed the cgi issue completely in my development environment. ------------------------------------------------------------------------ [2003-03-20 12:30:21] ottawasixtyseven at hotmail dot com 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 ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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