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 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... ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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
