Page MenuHomePhabricator

$wgUseFileCache with $wgUseGzip fails when Apache compression is enabled
Open, LowPublic

Description

$wgUseGzip is buggy in combination with wgUseFileCache and PHP accelerator

  1. This return garbage HTML: Some PHP accelerator + $wgUseGzip + $wgUseFileCache.
  1. 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


Version: unspecified
Severity: normal

Details

Reference
bz23368

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:04 PM
bzimport set Reference to bz23368.
bzimport added a subscriber: Unknown Object (MLST).

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.

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/

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 .

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

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