Last modified: 2012-06-20 12:34:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12124 - Fix support for FastCGI by not sending both "HTTP 1.x ###" and "Status: ###" headers
Fix support for FastCGI by not sending both "HTTP 1.x ###" and "Status: ###" ...
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.18.x
PC Linux
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 29897 34112 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-26 19:00 UTC by Ben Wilhelm
Modified: 2012-06-20 12:34 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ben Wilhelm 2007-11-26 19:00:05 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.
Comment 1 Mark A. Hershberger 2012-02-01 16:45:47 UTC
*** Bug 34112 has been marked as a duplicate of this bug. ***
Comment 2 Uwe Kaminski 2012-02-01 18:27:27 UTC
(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
Comment 3 Bawolff (Brian Wolff) 2012-02-02 01:58:58 UTC
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]
Comment 4 Uwe Kaminski 2012-02-04 10:53:36 UTC
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
Comment 5 Uwe Kaminski 2012-02-07 18:49:43 UTC
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.
Comment 6 Krinkle 2012-06-20 08:16:36 UTC
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.
Comment 7 Krinkle 2012-06-20 08:18:03 UTC
*** Bug 29897 has been marked as a duplicate of this bug. ***
Comment 8 Bawolff (Brian Wolff) 2012-06-20 12:19:10 UTC
Agreed on both points of comment 6 (especially the first point)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links