Bug #8744 Updated: call to header() causes CGI error
| From: | lobbin@php.net | Date: | Sat, 12 Jan 2002 11:55:40 +0000 |
| Subject: | Bug #8744 Updated: call to header() causes CGI error | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-76754@lists.php.net to get a copy of this message | ||
ID: 8744
Updated by: lobbin
Reported By: emily@crytech.com
Old Status: Open
Status: Feedback
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.0.4pl1
New Comment:
How does this work on 4.1.1?
Previous Comments:
------------------------------------------------------------------------
[2001-02-12 17:30:21] phanto@php.net
i have the same problem here. when i turn on the log startup errors
flag in the php.ini i get the following output :
______________
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
FATAL: erealloc(): Unable to allocate 1043162510 bytes
______________
i guess there's something wrong within the parser or compiler, because
nothing of the code is executed.
unfortunatelly i don't have 1GB RAM so i would be happy if there is any
solution to this.
harald.
------------------------------------------------------------------------
[2001-01-16 18:30:59] emily@crytech.com
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=5&New=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=5&ProbRevID=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
------------------------------------------------------------------------
[2001-01-16 18:29:28] emily@crytech.com
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] derick@php.net
Can you tell us what is in the logs of IIS?
------------------------------------------------------------------------
[2001-01-16 14:07:45] emily@crytech.com
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.
Thanks in advance for any feedback.
------------------------------------------------------------------------
Edit this bug report at http://bugs.php.net/?id=8744&edit=1