ID: 25863
Comment by: david dot blair at nsi1 dot com
Reported By: salmanarshad2000 at yahoo dot com
Status: Closed
Bug Type: CGI related
Operating System: win32 only
PHP Version: 4CVS, 5CVS, 6CVS..
New Comment:
I can add onto / narrow down salmnarshad's info a bit:
I just had this error start popping up on pages where my main frame had
images added to it. I've had an image on the menu frame (which does not
get updated) and it hasn't caused any errors before.
In comparing against Salmnarshad's info my test cases are:
-Running PHP 4.3.4 on a 2000 server as CGI under IIS
-Running under 2 frames (only the main frame is being updated)
-I'm making MSSQL calls not MySQL calls on both the calling page, and
the next page displayed
-Using a header("Location: yada yada") redirect to move between pages
-The MSSQL connection is being closed just before the redirect, and
reopened right after it...it is not being left open
-Our server is running over 1ghz
-Pages are being viewed by client machines (errors have occurred
haphazardly on different clients, we have been unable to replicate the
error everytime)
Simplest solution seems like the easiest for me...I'm going to dump the
images from the pages that are causing this problem to try and resolve
it quickly on my end.
Previous Comments:
------------------------------------------------------------------------
[2004-04-23 08:39:44] steve at xcvr dot com
I've had had this issue occur in my fresh installation of 4.3.6 (Win2K,
CGI), even after applying all the recommended
fixes/changes/configurations. So far, I've found that if I remove one
particular image, the problem goes away. Put the image back, and the
problem creeps up again. I've changed around the <img> tag, and still
cannot get rid of the "...CGI application misbehaved...".
FWIW, this page uses SSL.
------------------------------------------------------------------------
[2004-01-27 07:06:04] salmanarshad2000 at yahoo dot com
Saw the problem for two more days after installing PHP version 4.3.4
(replacing version 4.3.3), after that the problem completely
disappeared.
------------------------------------------------------------------------
[2003-12-12 16:46:57] nigel dot salt at hotmail dot com
I followed all the hints here but IIS 5 and PHP 5 would still not
behave. What was necessary in the end was:
1) Set
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script
Map]
".php"="your path to php\\php.exe"
2) ensure there is not a php.ini in the windows system folder and that
there is one wherever you've put PHP
3) edit php.ini and set cgi force redirect to 0 and
cgi.rfc2616_headers = 1
4) Put the PHP scripts in their own folder underneath the inetpub root
5) Open the IIS console, right click your new php folder
In the Directory tab
set application name to the name of the folder
set executable and script as permission
set application protection to low
Click configuration and check that .php is mapped to wherever you put
PHP
Restart IIS
Try a very simple PHP page and it should work
Nigel
------------------------------------------------------------------------
[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
