hi,
now i have a very short script that reproduces the error:
?php
$count = 0;
session_start();
$count++;
session_register("count");
sleep(1); // flood protection
if(TRUE)
{
header("Location: stress.php?".SID);
}
?
i don't think that the session stuff is required, the number of requests
until the error occured is very different, so i don't think it has something
to do with it.
VERY IMPORTANT: this only happened to me when header() was called inside
_OR_ after a structural block (if, while, function, switch, ..).
I'm using the latest cvs-version on Win2k / IIS 5.
I hope this is a valuable hint.
harald.
-Ursprngliche Nachricht-
Von: Harald Radi [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 17. Jnner 2001 19:13
An: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Betreff: AW: [PHP-DEV] PHP 4.0 Bug #8744 Updated: call to header()
causes CGI error
hi,
a few comments to this, my (afaik already closed) and the #8571
bug reports:
in fact the provided information about this bug is insufficient,
but it's definitly a bug.
since the error appears in irregular intervals with the same
script it's hard to find any
dependencies. i will try to find the shortest script that
generates this error.
a few hints:
when i use a https connection the error occours more often.
i don't get the error when i work local (on the webserver), but i
get it when i access the same machine remote.
it would be helpful if i could tell php to be more verbose. (i.e.
log internal function calls to see where the execution stops)
if someone could tell me how to debug php on a win32 platform i
would give my best to localize this bug.
harald.
resistance is futile - nme.at
-Ursprngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 17. Jnner 2001 00:31
An: [EMAIL PROTECTED]
Betreff: [PHP-DEV] PHP 4.0 Bug #8744 Updated: call to header() causes
CGI error
ID: 8744
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Description: call to header() causes CGI error
In case you missed my second message:
Here are two typical lines from the IIS error log: the first is a
successful page load (code 200) and the second is the CGI error
after the redirect (502) Note that in the IIS log format it is
normal for a space to separate the URL
and the Querystring. The last column in the log is the referrer URL.
2001-01-16 17:20:30 192.168.1.29 - GET /success/ProbRev.php3
EmpID=5New=Y
200 0 378 Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98;+Win+9x+4.90)
http://192.168.1.30/success/InterimRevSelect.php3?EmpID=5
2001-01-16 17:20:30 192.168.1.29 - GET /success/ProbRev.php3
EmpID=5ProbRevID=12 502 0 374
Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+98;+Win+9x+4.90)
http://192.168.1.30/success/InterimRevSelect.php3?EmpID=5
Previous Comments:
--
-
[2001-01-16 18:29:28] [EMAIL PROTECTED]
A few more things: the problem is not easily reproducible. Also,
if I change all of the database calls to go to mySQL (which I
have installed on Windows 2000) instead of SQL Server 2000 (which
is the database system I was using, also installed on the same
machine), I do NOT get the CGI errors. However, in both
instances, the databases do get updated or otherwise manipulated
successfully; it's just the redirect that fails when using SQL
Server. Hope this helps.
--
-
[2001-01-16 14:12:01] [EMAIL PROTECTED]
Can you tell us what is in the logs of IIS?
--
-
[2001-01-16 14:07:45] [EMAIL PROTECTED]
Our situation is similar to that in bug report 8571, particularly
situations 1 and 2. After adding, updating or deleting a record
to a MSSQL database, the user is referred to this function
(stored in file which is included in each page):
function pageRedirect($inURL) {
header("Location: $inURL");
exit;
}
$inURL is never exactly the same as the current URL - either you
are redirected to a completely different file name, or to the
same file name with a different query string appended.
The record modification part always completes successfully in
MSSQL, and the header() function sends the user to the new URL,
but this error occurs:
[start]
CGI ERROR
CGI application misbehaved by not returning a complete set of
headers. The headers that it
did return are:
[end]
... and any code in the page that the user has been redirected to
is NOT executed. If the user clicks refresh, it does and all is well.
This is a PHP web application being ported from a Linux/mySQL
environment, where it works, so it appears to be an IIS-specific issue.
Than
