[HTTP 330] ERR_CONTENT_DECODING_FAILED
Lost CSS styling—frontend and backend
Gzip compressionHow To Optimize Your Site With GZIP Compression is a bit of a mixed bag. While it can improve data transfer speeds and, therefore, perceived better website performance at the client end, people should be careful using Joomla’s Gzip features if they don’t know how they work.
Misusing Joomla’s Gzip features can cause browser errors and can potentially result in you not being able to manage your website. There are two different problems relating to Gzip in Joomla: (1) content encoding errors and (2) loss of CSS styling—frontend and backend—also known as the J! 4 “double gzip” problem.
[HTTP 330] ERR_CONTENT_DECODING_FAILED error
All versions of J! 3.x/4.x include a setting to utilise Gzip compression in Joomla. This setting is located at System » Global Configuration » Server » Gzip Page Compression. The setting is normally disabled by default, that is Gzip Page Compression = No . Under certain circumstances, enabling this setting can result in content encoding problemsContent Encoding Error when viewing an unpublished article—Joomla Forum, 10-Mar-2022.
The problem may be that your server already has Gzip compression turned on. When the server “gzips”, and then Joomla tries to “gzips” again, it can cause some weird encoding issues. Contact your hosting company and find out if they “gzip” automatically and, if so, there is no need to have it on in Joomla as well. I have not observed any appreciable difference in performance with the setting enabled and it is my recommendation that, unless you understand what you’re doing, you’re probably better of leaving the configuration option untouched.
The J! 4.x “double gzip” problem
I did not coin the term “double gzip problem” and I was sceptical that there was something in the configuration settings in J! 4.x may be responsible for the problems that people were having as a consequence of renaming the htaccess.txt to .htaccess. However, after extensive investigation, the reports from several different sources confirmed there were suspicions about the way that the J! developers had constructed the htaccess.txt “template” file. So, while I feel that the phrase “double gzip problem” is a misnomer—perhaps “mishandled browser decompression” might be more suitable—I don’t think it’s necessary to debate the wording.
The second matter is a little more complicated and I will let you read the words of a forum users who describes the symptoms in this wayThe original forum message has been edited to improve readability and preserve the meaning.:
I created a new J! 4.x website and] … my issue … seems to be related to the SSL Certificate or URL Rewriting. With SSL installed everything is working [but] as soon I [try to use SEF URLs with URL Rewriting force] SSL enabled on backend of Joomla … [this problem] happens: [the browser displays] everything … in one single column … with no styling in backend and frontend. If I [don’t use] … URL Rewriting … [the] site works correctly but … shows the index.php [in the URL] which I [don’t want].forum user, Joomla Forum, 3-Apr-2022
Before we attempt to solve this problem, let’s see look at the picture of “the browser displaying everything in a single column with no styling in backend and frontend” (see the screenshot on the right of the screen).The screen capture was taken from a French-language website. In addition to what you see, there is an additional message saying “Warning! Internet Explorer should not be used for proper operation of the Administrator Backend”. Although support for Internet Explorer was dropped in J! 4.x this actually has nothing to do with the “double gzip” problem. When people encounter the problems we’re discussing in this article, J! is unable to detect the what browser is being used and generates the warning message as a default.
In order to understand the issue we need to look at the htaccess.txt file that’s distributed with Joomla. In an earlier article we talked about this htaccess.txt file. The file serves as a “template” to create your own distributed server configuration file [DSCF]. At the most basic level, in order to use the URL Rewriting option in Joomla, the actual DSCF only requires a couple of lines of code. The Joomla “template DSCF”, however, contains a lot of other instructions that are optional; these optional instructions are based on the developers’ personal experience but they are not mandatory in all situations.
There are a few differences between the htaccess.txt file shipped with J! 4.x compared to the versions distributed in older versions. In particular, the last thirty-two lines are new. The relevant new section relates to Gzip. Let’s look at them (lines 127-159):
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "\(1\.css\.gz" [QSA]
# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "\)1\.js\.gz" [QSA]
# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz\(" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz\)" "-" [T=text/javascript,E=no-gzip:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip
# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
As I mentioned above, several parts of Joomla’s htaccess.txt are optional and may be unnecessary for your own implementation of .htaccess rules, however this new section is causing a growing “double gzip” problem in J! 4.x. The solution to the problem is to delete the last section.
The “double gzip” problem after J! 4.2.9
The issues we’ve discussed above were eventually acknowledged by Joomla’s developers as “erroneous code” in the htaccess.txt file; this acknowledgement appears as a post-installation message from J! 4.2.9 (click the image at the right to enlarge it). It may be, as one possible reason why it took so long to find a solution, that website developers often work in more disciplined ways than novice users. For example, many people typically install new websites within sub-folders of other websites—this is sometimes referred to as website “nesting”—whereas people with more experience do not do this. While there’s nothing wrong with creating new websites within sub-folders of other websites, there may be special considerations people need to bear in mind when doing so.
I do not create my websites as sub-folders of other websites (and that’s one reason I don’t encounter many of the problems that I read about). While it’s my opinion that there is a better approach that nested websites, this subject deserves an article in its own right.
In any case, the admission by the J! project team of a problem that took over a year-and-a-half to address notwithstanding, the J! 4 “double gzip” problem will be around for a while longer.
