#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
| From: | pedro at fundacaounimed dot com dot br | Date: | Mon, 12 May 2003 12:27:01 +0000 |
| Subject: | #9852 [Com]: Header redirect and db connection cause "CGI misbehaved" | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-39487@lists.php.net to get a copy of this message | ||
ID: 9852
Comment by: pedro at fundacaounimed dot com dot br
Reported By: ron dot baldwin at sourceprose dot com
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
I think I find the solution for this problem (at least on version
4.3.1)...
Just put this line "cgi.rfc2616_headers = 1" on php.ini.
Please, send us a message if it works. I had this problem during much
time and looking for solution, I saw that many others have it too.
PS.: sorry if there is some english error.
Previous Comments:
------------------------------------------------------------------------
[2003-04-17 20:43:39] ottawasixtyseven at hotmail dot com
Parsnip, it's an IIS bug. Have you tried php4isapi.dll? It completely
fixes this problem. I can send you my breakiis.exe so you can prove to
your managers that IIS can't handle multiple simultaneous to any CGI.
The trick is to get away from CGI.
This is right off the Microsoft site:
"The Internet Server Application Programming Interface (ISAPI) model
was developed as a higher-performing alternative to the Common Gateway
Interface (CGI). ISAPI provides a number of advantages over CGI,
including low overhead, fast loading, and better scalability."
"The chief difference between the CGI and ISAPI programming models is
the way processing is handled. With CGI, the system creates a unique
process for every request. Each time an HTTP server receives a request,
it initiates a new process. Because the operating system must maintain
all these processes, CGI is resource-intensive. This inherent
limitation makes it difficult to develop responsive Internet
applications with CGI."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/htm/ISAPIExtensions.asp
Ottawa
------------------------------------------------------------------------
[2003-04-10 11:58:54] parsnip11 at hotmail dot com
I'm using windows 2000 advanced server, service pack 3, pentium 2.2
ghz, 512 ram. The Usleep function is working for me intermittently and
sometimes solves the problem.... mostly it's effective if I do a
javascript redirect as opposed to using the header command.
All patches and performance changes mentioned here havent done a thing
to change this bug.
PHP PEOPLE ---> You have just GOT to open this bug up. I can only work
with iis in my current enviornment and not being able to do redirects
with PHP is just crippling my applications.
Huffing that Microsoft's products are broken is not an acceptable
solution. This exactly the kind of thing that make managers say "I told
you it should have been done in asp... enough with your goofy php!".
please fix this bug!
------------------------------------------------------------------------
[2003-04-08 04:14:49] jitse dot groen at grib dot nl
Dear all,
I'm probably not as experienced in PHP as all of you but I found a
solution that *seems* to work fine for our sites. I base this on tests
with doit.php by frankielam.
I should also mention running iisreset once in a while decreased the
number of CGI errors per day. It takes about 1-2 weeks for the bug to
become noticable to us. It is present before that time but will not
show that often.
Changing performance to optimize for applications I really cannot
consider. How can reducing the speed of our servers be a solution?
A possible solution though: After increasing the paging file size
(virtual memory) I cannot reproduce the bug however often I try. I'm
not absolutely convinced that this will do the trick, but for now, it
works. I would be anxious to hear your experiences with this solution.
With kind regards,
Jitse Groen,
The Netherlands
------------------------------------------------------------------------
[2003-03-21 07:31:33] lewid at nc dot rr dot com
Thank you very much for all you comments, Ottawa67!
I have implemented ISAPI using php4isapi.dll in our production
environment now and it appears to work perfectly and has solved the
problem we were having.
I will contribute any bugs I encounter but so far it is working ...
perfectly!
------------------------------------------------------------------------
[2003-03-20 17:10:36] ottawasixtyseven at hotmail dot com
Lewid,
php4isapi.dll works perfectly for some people. We are part of the
unfortunate group that experiences lots of server 500 errors. Here is
an excerpt from the latest PHP INSTALL text file:
_________________________________________________
PHP 4 for Windows comes in two flavours - a CGI executable (php.exe),
and several SAPI modules (for exapmle php4isapi.dll). The latter form
is new to PHP 4, and provides significantly improved performance and
some new functionality. However, please note that the SAPI modules are
*NOT* yet considered to be production quality. In particular, with the
ISAPI module, you are likely to encounter serious reliability problems
especially on platforms older than W2K - you may witness a lot of
server 500 errors and suffer from other server modules such as ASP also
failing. You have been warned!
The reason for this is that the PHP SAPI modules are using the
thread-safe version of the PHP code, which is new to PHP 4, and has not
yet been tested and pounded enough to be considered completely stable,
and there are actually a few known bugs. On the other hand, some people
have reported very good results with the SAPI modules, and there a few
reports of problems with the Apache module version. In short - your
mileage may vary; If you need absolute stability, trade the
performance of the SAPI modules with the stability of the CGI
executable.
_________________________________________________
Hopefully you can be part of the increasing numbers that are actually
able to give php4isapi.dll a good pounding. Please make sure to report
any problems you have with it.
Ottawa
------------------------------------------------------------------------
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/9852
--
Edit this bug report at http://bugs.php.net/?id=9852&edit=1