#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: Hi All, I installed the patch for Q318089 (MS02-009) and the error still occurs. It's also interesting to note that after running IRIS (network packet sniffer) it seems that IIS is not even launching PHP since the header "X-Powered-By: PHP/4.2.3" does not show up. I can only guess in that something with IIS/PHP/MSSQL connectivity, the PHP executable (child handles/threads) are being locked in use which prevents PHP from launching, however a local administrator on the box has sufficient priviledges to over-ride these locks and PHP is launched. -- Packet from IRIS -- GET /image_viewer.php?strPhotoID=99cBiFieBDiBaHBHcBac&strThumb=1 HTTP/1.1 Accept: */* Referer: http://website/test.php Accept-Language: en-au Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) Host: website Connection: Keep-Alive Cookie: PHPSESSID=b3cfba912345ad3043a08bd6d6faf16d HTTP/1.1 502 Gateway Error Server: Microsoft-IIS/5.0 Date: Wed, 25 Sep 2002 01:18:12 GMT Connection: close Content-Length: 215 Content-Type: text/html Error in CGI Application CGI ErrorThe specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: --- Regards David Previous Comments: [2002-09-24 20:05:43] [EMAIL PROTECTED] After some further testing on this PHP bug, I'll have to claim my previous comment about upgrading MDAC to be a bit of a Red Herring. However, my comment about running the IIS slot as an Administrator is still valid, it seems that when the scripts are being executed as an administrator (either by setting the anonymous IUSR to be an administrator or removing anonymous access and authenticating with an administrator account), this bug didn't occur in the 200 or so requests that I made to the server yet when I drop the slot back to being run as the IUSR it fails immediately. The bug now seems to be not related to a Header redirect since I can replicate it almost every time without fail by browsing to one of my plain HTML pages which loads approximately 30 images by using a PHP script to produce the image. A database connection is created in that image script as it lookups the image's ID (a random 15 character string) which maps it to the physical location of the image. I have tried to throttle the bandwidth setting as mentioned earlier but with no success. I have also been seeing these "Application Popup Errors" at the same time that the PHP script returns its CGI Header error. This popups occur on the console and are exactly the same each time, they consist of; --- Title Bar: php.exe - Application Error The application failed to initialize properly (0xc142). Click OK to terminate the application --- Server Information: P3-1Ghz 512Mb RAM Win2000 Server (SP3), IIS5 Hotfixes: Q326830 Q295688 Q147222 IIS is configured to run as a host header server. Unfortunately in my circumstances, it prevents the company I work for the ability to allow our clients to use PHP on our live web servers until this bug is fixed up. If this bug can be re-opened and looked into, I'm sure we would all be very grateful for it. Cheers [2002-08-28 13:59:31] [EMAIL PROTECTED] A few notes to add to the above comment. Our client does not have the Performance Option set to foreground. The CGI error doesn't happen any more thanks to either MDAC 2.7 or MS02-009. Wish I knew which of the two fixed the CGI errors [2002-08-28 13:52:53] [EMAIL PROTECTED] I agree with Scott. PHP should be made to work with enterprise products. Even if the problem is not PHP's fault we still need to know exactly what causes it. It's very interesting that when Scott sets Performance Options to forground it solves his CGI error completely. It's even more interesting that MDAC 2.7 doesn't help him. This is our latest experience with a client who just installed our PHP application. Client System Configuration: 1.4 GIG processor, M$ 2000 Server, IIS, PHP, M$ SQL Server. Client installed our application. CGI errors out the ying-yang (this error happens more frequently on a machine with a fast processor). Told Client to install MDAC 2.7 RTM. Unfortunately (or fortunately depending on how you look at it), the client also decided to install this patch at the same time: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-009.asp So, we've found some new, interesting information from Micro$oft: "Incorrect VBScript Handl
#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: After some further testing on this PHP bug, I'll have to claim my previous comment about upgrading MDAC to be a bit of a Red Herring. However, my comment about running the IIS slot as an Administrator is still valid, it seems that when the scripts are being executed as an administrator (either by setting the anonymous IUSR to be an administrator or removing anonymous access and authenticating with an administrator account), this bug didn't occur in the 200 or so requests that I made to the server yet when I drop the slot back to being run as the IUSR it fails immediately. The bug now seems to be not related to a Header redirect since I can replicate it almost every time without fail by browsing to one of my plain HTML pages which loads approximately 30 images by using a PHP script to produce the image. A database connection is created in that image script as it lookups the image's ID (a random 15 character string) which maps it to the physical location of the image. I have tried to throttle the bandwidth setting as mentioned earlier but with no success. I have also been seeing these "Application Popup Errors" at the same time that the PHP script returns its CGI Header error. This popups occur on the console and are exactly the same each time, they consist of; --- Title Bar: php.exe - Application Error The application failed to initialize properly (0xc142). Click OK to terminate the application --- Server Information: P3-1Ghz 512Mb RAM Win2000 Server (SP3), IIS5 Hotfixes: Q326830 Q295688 Q147222 IIS is configured to run as a host header server. Unfortunately in my circumstances, it prevents the company I work for the ability to allow our clients to use PHP on our live web servers until this bug is fixed up. If this bug can be re-opened and looked into, I'm sure we would all be very grateful for it. Cheers Previous Comments: [2002-08-28 13:59:31] [EMAIL PROTECTED] A few notes to add to the above comment. Our client does not have the Performance Option set to foreground. The CGI error doesn't happen any more thanks to either MDAC 2.7 or MS02-009. Wish I knew which of the two fixed the CGI errors [2002-08-28 13:52:53] [EMAIL PROTECTED] I agree with Scott. PHP should be made to work with enterprise products. Even if the problem is not PHP's fault we still need to know exactly what causes it. It's very interesting that when Scott sets Performance Options to forground it solves his CGI error completely. It's even more interesting that MDAC 2.7 doesn't help him. This is our latest experience with a client who just installed our PHP application. Client System Configuration: 1.4 GIG processor, M$ 2000 Server, IIS, PHP, M$ SQL Server. Client installed our application. CGI errors out the ying-yang (this error happens more frequently on a machine with a fast processor). Told Client to install MDAC 2.7 RTM. Unfortunately (or fortunately depending on how you look at it), the client also decided to install this patch at the same time: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-009.asp So, we've found some new, interesting information from Micro$oft: "Incorrect VBScript Handling in IE can Allow Web Pages to Read Local Files" Micro$oft also talks about third party scripting languages: "... Microsoft has become aware of a handful of third-party applications that depend on unforeseen behavior in VBScript that this patch disables." So good news and bad news. Bad news: We don't know if MDAC 2.7 fixed our clients CGI erros or if the MS02-009 fixed it. Good news: we've found yet another possible solution (MS02-009) If anyone has a really fast machine out there maybe they can test this MS02-009 fix. Please post your findings here. Ottawa [2002-08-28 02:28:14] [EMAIL PROTECTED] Hi all, As a followup a few weeks later, I can confirm that setting the server performance to optimise for 'Forground Applications' solves the CGI Error problem completely. My guess is that PHP is launched as a CGI in user space (owned by IUSR_*), so tuning the server this way gives it more processing time. I guess the MSSQL module likes it this way. I have also had emails from others asking for assistance on this, and have had positive feedback from them that it fixed their problem, too. Scott. [2002-08-05 02:14:38] [EMAIL PROTECTED] Further to my other posts, some more constructive data
Bug #17357 Updated: odbc_fetch_row is broke in 4.2.1
ID: 17357 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: ODBC related Operating System: Windows 2000 Advanced Server PHP Version: 4.2.1 New Comment: If any of the other 12 respondents can produce code to demostrate, it will help.. mine is buried in an complex applications, and I will have to develop a demo scenario. I can tell you everthing worked fine on PHP 4.1.X, and broke when we upgraded to 4.2.X Only after we traced it did we find that the direct row specification on the ODBC_FETCH_ROW command was being ignored, and several other functions that would use similiar direct row addresses. Perhaps it was a compile error... I can't say. But it will take me a while to put together a set of demo functions and database schema... Previous Comments: [2002-05-28 16:59:41] [EMAIL PROTECTED] nothing has changed to the odbc_fetch_row function in the last... 3 or 4 releases. Can you please post a sample script, and a copy of a test schema (and data) to reproduce this problem. [2002-05-22 19:48:08] [EMAIL PROTECTED] I have experienced the same problem.. My PHP system is Windows XP running IIS and PHP 4.2.0. against a Windows 2K Server with MS-SQL 7.0. I worked around it by closing the connetion and the requerying... The odbc_num_rows also fails... and I had to do a loop of odbc_fetch_row to count the rows in the recordset, then close the connection, then requery. The OpenSource program "WebCalendar" also isn't working with ODBC in 4.2.0 in a Windows environment with SQL Server (can't speak for anything else)... it uses the odbc_fetch_array command...and that too seems to be failing without any error messages. [2002-05-22 09:09:09] [EMAIL PROTECTED] In previous versions of PHP you could reset the pointer on ODBC resutls using odbc_fetch_row($results,0). This no longer works! I can find no other way to reset ODBC results. If you check for results and then try to loop through the results, you will loose the 1st row! - Anthony -- Edit this bug report at http://bugs.php.net/?id=17357&edit=1
Bug #17357 Updated: odbc_fetch_row is broke in 4.2.1
ID: 17357 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: Windows 2000 Advanced Server PHP Version: 4.2.1 New Comment: I have experienced the same problem.. My PHP system is Windows XP running IIS and PHP 4.2.0. against a Windows 2K Server with MS-SQL 7.0. I worked around it by closing the connetion and the requerying... The odbc_num_rows also fails... and I had to do a loop of odbc_fetch_row to count the rows in the recordset, then close the connection, then requery. The OpenSource program "WebCalendar" also isn't working with ODBC in 4.2.0 in a Windows environment with SQL Server (can't speak for anything else)... it uses the odbc_fetch_array command...and that too seems to be failing without any error messages. Previous Comments: [2002-05-22 09:09:09] [EMAIL PROTECTED] In previous versions of PHP you could reset the pointer on ODBC resutls using odbc_fetch_row($results,0). This no longer works! I can find no other way to reset ODBC results. If you check for results and then try to loop through the results, you will loose the 1st row! - Anthony -- Edit this bug report at http://bugs.php.net/?id=17357&edit=1
