Last modified: 2012-01-07 22:40:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25368, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23368 - $wgUseFileCache with $wgUseGzip fails when Apache compression is enabled
$wgUseFileCache with $wgUseGzip fails when Apache compression is enabled
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-01 16:32 UTC by Subfader
Modified: 2012-01-07 22:40 UTC (History)
2 users (show)

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


Attachments

Description Subfader 2010-05-01 16:32:33 UTC
$wgUseGzip is buggy in combination with wgUseFileCache and PHP accelerator

1) This return garbage HTML: Some PHP accelerator + $wgUseGzip + $wgUseFileCache.

2) Certain page elements don't load with $wgUseGzip + APC:
Since I used $wgUseGzip the following page load mistakes occured randomly and mostly after page edit / submit actions:
* The sidebar was not loaded properly (the default layout is loaded).
* Page elements from the MediaWiki namespace didn't load at all, e.g. the CharInsert tools and apperead as "<CharInsert>" in plain text instead. Same for stuff loaded by Extension:HeaderFooter.

Since I don't know exactly what causes these errors I disabled $wgUseGzip. But I bet it's the usage of with APC again (which I won't disable).

Reports summed up from http://www.mediawiki.org/wiki/Manual_talk:$wgUseGzip
Comment 1 Markus Krötzsch 2011-09-25 19:57:00 UTC
I can confirm seeing the apparently same problem (1) on 1.17.0 using APC, gzip, and file caching as described above. The documentation page http://www.mediawiki.org/wiki/Manual:$wgUseGzip and its talk page http://www.mediawiki.org/wiki/Manual_talk:$wgUseGzip still claim that this is a bug and link to this page. But this page says that the bug is invalid.

Closing this bug as "invalid" (which it might well be) is not sufficient to solve the practical problem here. Somebody has to add a comment why it is invalid, especially explaining what else causes the issue for the affected users. Some common Web server misconfiguration? Or is the very use of these features in combination deliberately not supported by MediaWiki? Please clarify to close the matter properly.
Comment 2 Subfader 2011-09-25 20:58:10 UTC
I think I got very confused back then. Apache was using Gzip encoding by default already and $wgUseGzip = true; somehow doubled that. At least that's how I explained it to me.

Check if you're not sending gzipped already with APC + filecache + $wgUseGzip = false; and http://www.whatsmyip.org/http_compression/
Comment 3 Markus Krötzsch 2011-09-26 09:36:22 UTC
Yes, this is the case for me. But is this not still an MW bug? The setting $wgUseGzip = true; reduces cache size by gzipping the cached html. It also reduces the CPU load for gzipping cached pages on the fly. On the other hand, the Apache compression is independently useful if the server serves other content.

So the two settings are not alternative ways of doing the same thing, they merely overlap in some areas. It seems that one wants to have both features enabled. Could MW not somehow send the cached data in such a way that it is not re-zipped by Apache? Or is the solution to somehow configure Apache to not re-compress files when they come from the cache (how?)?

It seems there are the following options for this report:

(a) Close as "invalid" and declare that the asked-for function is not intended to be provided by MediaWiki at all (i.e. that MW is not generally usable with Apache compression) or that the error is on the side of Apache or its configuration.

(b) Close as "wontfix" and declare that this is an accepted problem/undesirable limitation of MediaWiki, but that its solution is too complicated to justify the investment of resources needed to fix it.

(c) Keep it open and eventually do something to allow the use of compressed caches on a server with default compression.

In case (a) and (b) the documentation on $wgUseGzip = true; should be updated to warn users of .
Comment 4 Markus Krötzsch 2011-09-26 09:39:12 UTC
<precious comment sent too early>
[to warn users of] the limitation, and to remove the existing warnings about APC et al. being involved in creating the issue.

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


Navigation
Links