Last modified: 2012-06-20 12:34:34 UTC
FastCGI spits out log errors similar to "[error] [client 1.2.3.4] 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 @@ global $wgOut; $wgOut->disable(); header( "HTTP/1.0 $code $label" ); - header( "Status: $code $label" ); $wgOut->sendCacheControl(); 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? Other questions: 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 /includes/resourceloader/ResourceLoader.php // 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)