Fix support for FastCGI by not sending both "HTTP 1.x ###" and "Status: ###" headers
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• bzimport
	Nov 26 2007, 7:00 PM

Description

Author: zorba-mediawiki-bugzilla

Description:
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.

Version: 1.18.x
Severity: normal
OS: Linux
Platform: PC

Details

Reference: bz12124

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:56 PM

• bzimport added a project: MediaWiki-General.

• bzimport set Reference to bz12124.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Nov 26 2007, 7:00 PM

Bug 34112 has been marked as a duplicate of this bug. ***

jukey wrote:

(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:

Change the Bug subject to: "Errors displaying pages with FastCGI: pages are displayed without CSS/style definition"?
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]

jukey wrote:

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

jukey wrote:

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

that is imho a stupid bug in FactCGI
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)

Aklapper lowered the priority of this task from Medium to Low.Mar 25 2015, 4:07 PM

Aklapper removed a subscriber: • wikibugs-l-list.Apr 12 2020, 9:55 AM

This has been solved. The HttpStatus abstraction no longer outputs a Status: header. MediaWiki only produces the HTTP/1.1 200 OK-style http status headers now.

Krinkle edited projects, added MediaWiki-ResourceLoader; removed MediaWiki-General.Apr 12 2020, 10:54 PM

Restricted Application added a project: Performance-Team. · View Herald TranscriptApr 12 2020, 10:54 PM

Fix support for FastCGI by not sending both "HTTP 1.x ###" and "Status: ###" headersClosed, ResolvedPublicActions

Description

Details

Event Timeline

Fix support for FastCGI by not sending both "HTTP 1.x ###" and "Status: ###" headers
Closed, ResolvedPublic
Actions