ID: 9852
Comment by: aha131 at yahoo dot com
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 tried all the solutions here but the problem still
I have PHP5 and IIS5.1 and MSSQL (Sql Server)
thanks
Previous Comments:
------------------------------------------------------------------------
[2004-07-27 00:08:01] perl at zeno dot com
I have this same problem with ActivePerl v5.8.4 on Win2003/IIS6. Using
the redirect header in CGI.pm, or printing one manually, fails only
sometimes with 502 errors logged by IIS. My observations:
Loading a .PL script which does a redirect will cause a 502 error if
the redirect points to another perl script, but never happens if I
redirect to a static HTML file.
The script I'm attempting to redirect TO loads just fine if loaded
directly from the browser.
The redirect header, oddly enough, DOES seem to reach the browser since
the URL bar of Mozilla contains the redirect destination URL, but the
server seems to simultaneously send a 502 error page.
Adding a delay of 1 second prior to the redirect does not help.
The problem does not occur if Anonymous Access is disabled. As long as
the user authenticates as *somebody*, the problem disappears.
The problem does not occur with the scripts on my Windows XP/IIS 5.1
box, ever.
I tried an older version of perl (5.8.0, I believe) with the same
effect. The fact that this is happening to PHP users too cements the
fact that this is an IIS bug with handling CGIs.
I tried configuring the anonymous user for the web to be a new user I
created called "BMAnon". I configured this user to be in the
Administrators group, as well as the Domain Admins group, and it did
not help.
I changing the Processor Scheduling option. For the first few loads it
seemed to help, but eventually the error still occurs.
The system is a Dual-capable (but single CPU) Intel Xeon from Dell with
1gb of RAM.
I have hundreds of other Perl scripts on the same server in other webs
(most of which use authentication) which open many DB instances,
sometimes as many as five, and I've never seen this problem on those
scripts. However, I rarely use the redirect function elsewhere so this
could just be the first time I've had a chance to see this bug.
IIS seems to have a problem when any remote user of an
anonymous-enabled webs invoke multiple CGI processes. I would even
suggest that one instance of a CGI attempting to redirect to another
CGI is the cause.
------------------------------------------------------------------------
[2004-06-23 18:42:29] php at squeg dot net
And, of course, I made a typo in my sample 502 page... The body tag
should be:
<body bgcolor="FFFFFF" onload="setTimeout( 'location.reload();', 50
);">
Note that I had double quotes around location.reload(); originally...
that certainly didn't work as expected =) Change the double quotes to
single quotes and all is well.
------------------------------------------------------------------------
[2004-06-23 18:36:00] php at squeg dot net
A temporary fix to this issue would be to create a custom 502 error
page that automatically refreshes the page (typically under
c:\WINNT\Help\issHelp\common - but don't forget that you also have to
set the options in Internet Services Manager... Go to Start, Programs,
Administrative Tools, Internet Services Manager. Click on your host,
then right click your website and select Properties. Then click the
"Custom Errors" tab. Find 502 in the list and ensure that it is set to
"File" and that it is pointing to your custom page).
The only problem with this approach is if the user was submitting a
form, they will be presented with a dialog box asking if they want to
"Retry" or "Cancel", so you should mention somewhere on your custom
page that they should click "Retry". Here's the custom page I hacked
together out of the default 502.htm for my university:
------------ BEGIN ------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html dir=ltr>
<head>
<style>
a:link {font:8pt/11pt verdana; color:FF0000}
a:visited {font:8pt/11pt verdana; color:#4e4e4e}
</style>
<META NAME="ROBOTS" CONTENT="NOINDEX">
<title>The page cannot be displayed</title>
<META HTTP-EQUIV="Content-Type" Content="text-html;
charset=Windows-1252">
</head>
<body bgcolor="FFFFFF" onload="setTimeout( "location.reload();", 50
);">
<h1>502: CGI Error</h1>
If it asks whether to Retry or Cancel, click <b>Retry</b>.
</body>
</html>
------------ END ------------
The reason I used setTimeout was because if I just used
location.reload(), MSIE doesn't display any text from the page, it just
reloads. So I figured a really small timeout value should make it
display the page first (just in case the user gets presented with that
"Retry/Cancel" box).
------------------------------------------------------------------------
[2004-02-26 05:41:44] stuart at gnqs dot org
I'm not sure why the PHP group haven't already done this themselves (I
will ask Wez when I see him next week ;-), but anyway. I have bug#
SRQ040206601696 open with Microsoft about this problem.
>From the analysis I've done so far (net trace of HTTP packets between
IE and IIS, ISAPI filter to do what tracing I can inside IIS, tracing
code added to PHP 4.3.5-rc1), the evidence comes down to this. When
this error occurs, there's no evidence of php.exe being executed - for
the repeatable test case that I have. What I can't *prove* (which is
partly why I've opened the bug w/ Microsoft) is whether IIS actually
tries to call php.exe or not.
Best regards,
Stu
------------------------------------------------------------------------
[2004-02-10 19:14:35] willy at vuboys dot nl
I also have experienced this problem. The PHP_ISAPI seems to fix it.
It seems this problem is related to a mssql connection. A solution
might be to add a header() at the beginning of the script (before the
mssql_connect). Is there a header of some kind which won't interfear
with the other headers the application might produce? Any
thoughts/comments on this?
------------------------------------------------------------------------
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
