Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

#25863 [Com]: IIS: The specified CGI application misbehaved

4 views
Skip to first unread message

mmyer at rightnowtech dot com

unread,
Nov 3, 2004, 10:15:37 PM11/3/04
to
ID: 25863
Comment by: mmyer at rightnowtech dot com
Reported By: salmanarshad2000 at yahoo dot com
Status: Open
Bug Type: CGI related
Operating System: win32 only
PHP Version: 4CVS, 5CVS, 6CVS..
New Comment:

We've spent an extensive amount of time investigating this and have
found a work-around for the PHP CGI error in the header("Location:
<url>") redirect case. In our experience, this was only encountered on
Windows 2003 Server and IIS 6, however it seems others have experienced
similar problems elsehwere.

First some observations:
1. As reported in bug #9852, changing the performance options fixes the
problem on slower hardware. With faster hardware, this had no effect.
Hence, it must be some kind of race condition. (to change this setting
r-click on My Computer -> Advanced -> Performance -> Advanced and select
Background Services)

2. If the php cgi did an odbc connection, the problem occurs. Without
the odbc connection, no problem.

3. If the php cgi wastes some time in a busy loop prior to issuing the
header() redirect, it works. For us, doing for($i=0; $i<1000000; $i++)
did the trick. Issuing a sleep() did not work. Strange, but again,
seems to indicate a race condition in IIS.

4. One of the previous posts mentioned that re-directing to the IP
address instead of the domain worked. This was the primary clue to the
solution.

Our solution:
The web browser will use the same TCP connection to send a subsequent
request if it receives a Location: redirect for the same domain. In
observation #4 above, it works because the re-direct is issued to an IP
address which causes the browser to think the redirect is to a different
system and close the existing TCP connection and make a new connection.
It seems that IIS has a problem if (a) the initial CGI execution occurs
very quickly and (b) a subsequent HTTP request is received over the
same socket as the first request. So the work-around is to force the
browser to close the TCP connection and open a new connection when a
redirect occurs. This can be done by issuing a "Connection: close"
header in addition to the "Location: redirect" header. The following
has solved the problem for us:

header("Connection: close");
header("Location: $url");

Hopefully some day Microsoft will fix this...


Previous Comments:
------------------------------------------------------------------------

[2004-10-16 02:04:49] marc at durdin dot net

The situation that I consistently see this bug in is:

header("Location: http://site/");

The error does not occur every time. To me, this does suggest a timing
issue. One piece of pertinent information is that the error is
occurring on the page redirected to, and not on the page doing the
redirection, as you can see from the following log entries. Steps
taken to generate this were: Open web browser to default page
(index.php), click on link to home.php - which detects that I am not
logged in and redirects to login.php (which then fails with error
502).

2004-10-15 23:37:39 192.168.20.9 GET /index.php - 80 - 192.168.20.11
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322)
200 0 0
2004-10-15 23:37:41 192.168.20.9 GET /home.php - 80 - 192.168.20.11
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322)
302 0 0
2004-10-15 23:37:41 192.168.20.9 GET /login.php - 80 - 192.168.20.11
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322)
502 2 0

It's a real pain - IIS doesn't give any detail in its logs about the
error, there are no eventlog entries, etc., and running it through Zend
Server Debugger shows no issues in the headers that I can see.

This is basically the code I am using to redirect:

header("Location: http://" . $_SERVER['HTTP_HOST'] .
str_replace("\\", "/",
dirname($_SERVER['PHP_SELF'])) . $page);
exit;

------------------------------------------------------------------------

[2004-10-14 08:25:39] winterpalace at netspace dot net dot au

Damn. Comment above isn't solution. 1 app appears to be okay , but
another is still having problems. The \ is not the cause.

------------------------------------------------------------------------

[2004-10-14 07:49:07] winterpalace at netspace dot net dot au

We have experienced similar probs here, except with Windows 2000
Server, CGI, and using MS SQL Server 2000.

I have a theory:
The DB function calls are a red herring.
It's the redirection that's the problem.
IIS is telling the truth.
The location isn't valid.

Basis:
Switched to FireFox, started getting messages about the location not
being found (where usually I'd get the CGI error). Looked at the code
I use for redirection:
header("Location: http://" . $_SERVER['HTTP_HOST'] .
dirname($_SERVER['PHP_SELF']) . "nextpage.php");
Found that dirname function was returning a "\" not a "/".
Rewrote this as:
header("Location: http://" . $_SERVER['HTTP_HOST'] .
str_replace("\\","/",dirname($_SERVER['PHP_SELF'])) . "nextpage.php");

No. More. Probs. (as yet :-))
Needs testing on other setups, go ahead :-).

------------------------------------------------------------------------

[2004-10-05 00:13:52] true_weakness at hotmail dot com

Hi All i have a windows 2003 sErver running IIS 6, I had the same
problem with the cgi timeout, resolved by
Downloading the IIS 6 resource kit.
http://download.microsoft.com/download/7/8/2/782c25d3-0f90-
4619-ba36-f0d8f351d398/iis60rkt.exe
With the IIS Metabase Explorer, go to the Server name, Expand
LM, Go to W3SVC. Find event CGI Timeout and change the
default from 300 secs to whatever you need and it works

------------------------------------------------------------------------

[2004-09-30 22:52:02] mlisondra at lisondra dot biz

This has occured in my applications that use PHP 4.3.6
with a MS SQL server backend.
Using Windows 2000 Server.

------------------------------------------------------------------------

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/25863

--
Edit this bug report at http://bugs.php.net/?id=25863&edit=1

dan at hostway dot nl

unread,
Nov 9, 2004, 8:36:30 AM11/9/04
to
ID: 25863
Comment by: dan at hostway dot nl

Reported By: salmanarshad2000 at yahoo dot com
Status: Open
Bug Type: CGI related
Operating System: win32 only
PHP Version: 4CVS, 5CVS, 6CVS..
New Comment:

Hi all!

Actually, all you need to do is specify a MIME type. Put this line at
the top of your code, and voila!

http://bugs.php.net/bug.php?id=25863

Pretty simple really... ;)


Previous Comments:
------------------------------------------------------------------------

[2004-11-04 04:12:02] mmyer at rightnowtech dot com

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view

dan at flowofchi dot nl

unread,
Nov 9, 2004, 8:37:48 AM11/9/04
to
ID: 25863
Comment by: dan at flowofchi dot nl

Reported By: salmanarshad2000 at yahoo dot com
Status: Open
Bug Type: CGI related
Operating System: win32 only
PHP Version: 4CVS, 5CVS, 6CVS..
New Comment:

Whoops!

Here is the line to add:

print "Content-type: text/html\n\n";


Previous Comments:
------------------------------------------------------------------------

[2004-11-09 14:36:25] dan at hostway dot nl

Hi all!

Actually, all you need to do is specify a MIME type. Put this line at
the top of your code, and voila!

http://bugs.php.net/bug.php?id=25863

Pretty simple really... ;)

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view

0 new messages