ID: 25863 User updated by: salmanarshad2000 at yahoo dot com Reported By: salmanarshad2000 at yahoo dot com -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows XP, 2000 PHP Version: 4.3.3 New Comment:
Test Case 1: ------------ I open up my browser and type the following url: http://localhost/phpMyAdmin/index.php The frameset page opens up correctly (phpMyAdmin uses 3 frames) but inside each frame I see the following error: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: I right click in one frame and select "Refresh" and this time page appears normally (CSS was missing though). I repeat the process for other two frames and each one displays it's contents properly. Test Case 2 ------------ I type the following url: http://localhost/salman/netoffice/index.php (NetOffice 2.5.2 is available at www.sourceforge.net) The url changes to http://localhost/salman/netoffice/login.php CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Refreshing the page opens the login page correctly. Test Case 3 ------------ I created a frameset page (container.php) with 9 frames each one of them calls frame.php?id=<RANDOM NUMBER> Inside frame.php there are simple echo statements and a loop of 1 to 10000 No problem occurred this time, all frames loaded normally. Later I added a "SELECT * FROM Northwind.Customers" call to MS SQL Server 2000 in frame.php using mssql_*() functions and it worked fine too. ------------ Here is a snapshot of IIS5 log for test case 1 and 2, I thought it might be useful. #Software: Microsoft Internet Information Services 5.1 #Version: 1.0 #Date: 2003-10-15 09:46:45 #Fields: time c-ip cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status #---------TEST CASE 1 09:46:45 127.0.0.1 GET /phpMyAdmin/css/phpmyadmin.css.php lang=en-iso-8859-1&js_frame=right 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/left.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/queryframe.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/main.php lang=en-iso-8859-1&server=1 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/index.php - 200 0 #---------HERE I START RIGHT CLICK->REFRESH FRAME ONE BY ONE 09:46:49 192.168.0.2 GET /phpMyAdmin/css/phpmyadmin.css.php js_frame=left&num_dbs=0 502 0 09:46:49 192.168.0.2 GET /phpMyAdmin/images/pma_logo.png - 304 0 09:46:49 127.0.0.1 GET /phpMyAdmin/left.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 200 0 09:46:51 192.168.0.2 GET /phpMyAdmin/css/phpmyadmin.css.php lang=en-iso-8859-1&js_frame=right 502 0 09:46:51 127.0.0.1 GET /phpMyAdmin/main.php lang=en-iso-8859-1&server=1 200 0 09:46:53 192.168.0.2 GET /phpMyAdmin/css/phpmyadmin.css.php lang=en-iso-8859-1&js_frame=left&num_dbs=0 502 0 09:46:53 127.0.0.1 GET /phpMyAdmin/queryframe.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 200 0 #---------TEST CASE 2 09:47:08 127.0.0.1 GET /salman/netoffice/index.php - 302 0 09:47:08 127.0.0.1 GET /salman/netoffice/general/login.php NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 502 0 09:47:13 127.0.0.1 GET /salman/netoffice/javascript/general.js - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/javascript/overlib_mini.js - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/themes/default/stylesheet.css - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/themes/default/calendar.css - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/general/login.php NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 200 0 09:47:27 127.0.0.1 POST /salman/netoffice/general/login.php auth=test&NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 302 0 09:47:27 127.0.0.1 GET /salman/netoffice/reports/selecthours.php typeReports=custom&NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 502 0 09:47:29 127.0.0.1 GET /salman/netoffice/javascript/calendar.js - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/javascript/general.js - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/javascript/overlib_mini.js - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/themes/default/stylesheet.css - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/themes/default/calendar.css - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/themes/default/spacer.gif - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/reports/selecthours.php typeReports=custom&NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 200 0 Previous Comments: ------------------------------------------------------------------------ [2003-10-14 20:33:39] [EMAIL PROTECTED] Please provide short test case (all settings, script(s) whatever else is needed to reproduce this) so we can reproduce this ourselves. ------------------------------------------------------------------------ [2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com Description: ------------ This bug or issue has been around for quite a while and seems like nobody cares. The bug list is filled with hundreds of complains about the "The specified CGI application misbehaved ..." error each time these people have BOGUSed or CLOSEd saying things like "The version you are using is too old, please try the latest version ...", "This is not a php bug, please go to ...", "Not enough evidence ..." or "Problem with Windows, not PHP". Quite a few versions of php have been released in the meanwhile, but this issue hasn't been fixed, people who upgrade their php installation come back with the same complains. I see no good reason for this ignorance. Problem Statement ----------------- When browsing a php application, the IIS server randomly throws the error message: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: <BLANK> Observations ------------ This happened only when: - PHP.exe is used as a CGI on IIS - The php scripts contained 2 or more frames (e.g. phpMyAdmin) - MySQL operation was executed (update, insert, delete etc.) - header("Location: ...") is used to redirect user after a MySQL operation to a page that also performs a MySQL operation - The pages are viewed from local computer - A very fast computer is used This did not happened when: - Apache server for windows with php support was used - The php scripts contained 2 or more frames but all frames contained php scripts with Hello World and a random number - Frequency of errors was much lesser when same pages were accessed from the network - Pentium 2, 300 MHz was used (a slow computer) History ------- Following bugs are all related to this problem. This is just a reminder for the fact that this issue has been discussed quite a few times and it is still present. People also found these interesting things that might help to get the problem solved. - BugID #25567 getting errors when doing a mysql_db_query() and then header("location") - BugID #24916 header("location") - BugID #23208 using two or more frames - BugID #19381 no details :( - BugID #19676 works on one (slow) system but does not work on other - BugID #18901 header("location") after delete or update, error occurs under under load - BugID #16313 header("location") and db operations - BugID #23050 mysql_query() followed by header("location") - BugID #17468 header("location") - BugID #9852 thousands of lines describing the problem, including frames, manually slowing down the script, pages work from outside the machine nut not locally, two database connections in rapid succession etc Things that have been said earlier ---------------------------------- "This is a problem with Microsoft OS" No this is not, it works on exact same OS running on slower hardware or when the application is accessed across a network. And even if it is, the developers should try to find a work around instead of blaming M$ and telling it to fix it. After all, when you develop some app for an environment, you don't change the environment to suit your app (although sometimes it is easier to do so). "This is not a php bug" Well this could be right, since there is one other suspect, MySQL. But somebody please figure out where the problem is? Also, MySQL is now an integral part of php so problem could lie in the integration part. My Opinion ----------- May be php.exe is not fast enough to keep up with the pace at which IIS can throw requests at it. Or ... may be it is a problem with the MySQL connections ... attempting to create connections too quickly may be the cause. Users having same problem please feel free to contribute with their observations and suggestions. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=25863&edit=1
