What browser, version, platform is this with?

My setup:
Windows 2000 Profesional Service Pack 2 + hotfixes
IE 5.5 Service pack 1
Mozilla 0.9.5

I have been looking around the code and what I could observe is that the problem has something to do with print_header_redirect() and setting cookies.

Case in point:
The login screen. With Quick Proceed on the I get bounced back to the login page. Quick Proceed uses print_header_redirect() to send me to the correct page after a login attempt. The thing is that when quick proceed is on, the cookies do not get created/updated, so in the next page (login_select_proj_page.php for example) the login check fails, and I get bounced back to the login page.

The problem with view_all_bug_page.php is that it checks to see if the correct cookie is set, if it is not, it sets it and print_header_redirect()'s me back to the same page. Since when print_header_redirect() is used the cookies are not being created/updated, the check fails and I get redirected to view_all_bug_page.php over and over. Seems like it is redirecting before the cookies are set for some reason.

My server setup is the following:
Windows NT 4.0 Service Pack 6a
PHP 4.0.6 running in CGI mode

Noticed that quick proceed it on here and the cookies are written, but then it's another webserver and another OS.

Looking around the PHP Manual notes for setcookie() found the solution. The problem is a bug in IIS when running CGI's (KB article: <a href="http://support.microsoft.com/support/kb/articles/Q176/1/13.ASP">http://support.microsoft.com/support/kb/articles/Q176/1/13.ASP</a>).
When the header Location is used, messes up with Set-Cookie.

The solution is using Refresh.

in line 20 in core_print_API.php change
header( "Location: $p_url" );
for
header( "Refresh: 0;url=$p_url" );

This solves both the looping I had at the login screen with Quick Proceed enabled, and this bug.

Ok, so since it's a MS bug I can just create a new global to fix this. I'll get this into CVS shortly.

well, as far as I have seen, it works exactly the same way as Location works here. Wouldn't it be more efficient to just make the change in core_print_API.php instead of making a new global?

My 2 cents

It's not standard behavior and it works correct for Apache. That tells me that this should be an exception case for IIS. Even MS states that this is a bug.

No problemo,
but I forgot to mention that if one uses
header( "Refresh: 0;url=$p_url" );
then also is necesary to comment
header( "Status: 302" );

because it makes Netscape and IE (5.5 and 5.01 which I tried on) display a "Document contains no data" (NS) and "Server not found" (IEs) message, which somehow makes sense since we'd be trying to do a Refresh: on a Temporarily Moved document. It must be noted that Mozilla 0.9.5 didn't need the commenting of the Status header.

My print_header_redirect now looks like this:

function print_header_redirect( $p_url ) {

header( "Status: 302" );

header( "Content-Type: text/html" );
header( "Pragma: no-cache" );
header( "Expires: Fri, 01 Jan 1999 00:00:00 GMT" );
header( "Cache-control: no-cache, no-cache=\"Set-Cookie\", private" );
header( "Refresh: 0;url=$p_url" );

}

and works fine with IE 5, 5.5, Netscape 4.7 and Mozilla 0.9.5.

Great. Thanks, I'll be releasing later tonight or tomorrow.

Fixed in CVS. Will be in 0.15.11