Last modified: 2012-06-20 12:34:34 UTC
FastCGI spits out log errors similar to "[error] [client 188.8.131.52] FastCGI: comm with server "/var/www/fastcgi/php-cgi" aborted: error parsing headers: duplicate header 'Status'" when attempting to display a MediaWiki error page, also causing 500 internal server errors for the user. This is because FastCGI+PHP is significantly stricter about headers than base Apache is, and does not like it when you set Status explicitly.
--- oldglobfunc.php 2007-11-26 18:55:20.000000000 +0000
+++ GlobalFunctions.php 2007-11-26 18:55:29.000000000 +0000
@@ -1144,7 +1144,6 @@
header( "HTTP/1.0 $code $label" );
- header( "Status: $code $label" );
header( 'Content-type: text/html; charset=utf-8' );
This fixes it. I do not know if it has unfortunate side effects on other platforms or with other libraries.
To duplicate: set up FastCGI with PHP, install MediaWiki, do something to generate an error page. This bug won't trigger without an actual MediaWiki error page - in my case it was a circular redirect caused by $wgUsePathInfo being off.
Let me know if I can provide better information somehow.
*** Bug 34112 has been marked as a duplicate of this bug. ***
(In reply to comment #0)
> This is because
> FastCGI+PHP is significantly stricter about headers than base Apache is, and
> does not like it when you set Status explicitly.
> - header( "Status: $code $label" );
> This fixes it. I do not know if it has unfortunate side effects on other
> platforms or with other libraries.
> To duplicate: set up FastCGI with PHP, install MediaWiki, do something to
> generate an error page. This bug won't trigger without an actual MediaWiki
> error page - in my case it was a circular redirect caused by $wgUsePathInfo
> being off.
As written in Bug 34112 this happens _on every page_ (not only error pages) as written in the bug description here.
You can see the result there: http://n9wiki.de
Go to this page and press F5: CSS are gone.
Press Ctrl+F5 (Firefox): Page is loaded including CSS. (You can find my logs in Bug 34112)
So it seems to be that the duplicated header only is generated if a page or related objects are cached somehow. Does this help?
Could you please:
1. Change the Bug subject to: "Errors displaying pages with FastCGI: pages are displayed without CSS/style definition"?
2. Set the Mediawiki version to 1.18.1?
Thank you very much, Uwe
Updated summary: Sending status codes in multiple ways causes php-fastcgi to crash and burn. This happens most notably in MediaWiki when RL sends a 304 not modified. (Also happens on certain error pages, but the RL is most prominent example)
The php people seem to think this is not a bug https://bugs.php.net/bug.php?id=33225 (which quite frankly seems stupid imho)
(With that said, we should probably try to address it somewhat on our end). Is there any good reason to do things like:
header( 'HTTP/1.0 304 Not Modified' );
header( 'Status: 304 Not Modified' );
One after each other? (Oh wait i know, because php's documentation tells us to: http://php.net/manual/en/function.header.php ).
So in conclusion, php sucks ;)
[I'm changing component to RL, eventhough not strictly an RL issue, and upping the priority slightly since it affect not just error pages anymore, and changing the version field]
This bug prevents the usage of Mediawiki in environments using FastCGI completely. As there also is no workaround (yet) I suggest to increase the priority/importance of this bug. Thanks
This piece of solves this problem:
If you are using FastCGI just remove this single line of code in
// header( 'HTTP/1.0 304 Not Modified' );
header( 'Status: 304 Not Modified' );
I assume this should be fixed also in other places of the whole source.
Is the problem that two code paths both send a "Status:" header? Or is the problem that there is both a HTTP 1.x status header and a "Status: " header (not the same twice, but similar types of header).
If "Status:" is only for FastCGI and FastCGI only works if there isn't an HTTP header as well, then
1) that is imho a stupid bug in FactCGI
2) we should probably centralize the logic for sending status headers in a public static method (using HttpStatus::getMessage() for the message) somewhere and implement that everywhere.
*** Bug 29897 has been marked as a duplicate of this bug. ***
Agreed on both points of comment 6 (especially the first point)