Content encoding error
A few people have been experiencing the following error. UPDATE: The reason for it happening is because when your browsers request a page from us, we compress it when we send it back. This allows us to send your page faster, and to send more pages to more people simultaneously. Some browsers (either older ones or ones where the deafult settings have been changed) do not accept compressed pages and have to be told to do so.
We recommend that you use the latest versions of Firefox, Safari (my personal favourite) or Google Chrome to access the site (and the internet in general).
“Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
* Please contact the web site owners to inform them of this problem.”
One of our customers (Matthew McGinlay) has very kindly posted a solution, as below. Thank you Matt!
The fix is for firefox
1) In the address bar type “about:config” (but without the inverted commas)
2) Tell it that you will be careful, Promise!!
3) In the filter type encoding
4) There should be one option reading “network.http.accept-encoding”
5) Click in the value column and type “true” (again without the inverted commas)
6) This should fix it and you can search to your hearts content.
January 15th, 2009 at 5:00 pm
Yes, that fixes *your* website, but leaves lots of others broken (eg youtube!). What funky compression are you using? You’re the only website I’ve encountered that triggers this problem. I’ve had to add a special exception to our web proxy so that our users can access your site.
(acl broken_encoding dstdomain http://www.1911census.co.uk
header_access Accept-Encoding deny broken_encoding
for squid 2.6)
January 15th, 2009 at 6:34 pm
The suggested change to Firefox’s about:config sounds highly dubious to me. It may work around the reported problem on 1911census.co.uk, but I’d strongly warn people against changing it unless they can be absolutely sure that there are no detrimental side-effects.
In Firefox 3, network.http.accept-encoding appears *not* to expect a true/false value. Under normal circumstances the value of this setting should be ‘gzip,deflate’, which are the names of HTTP content encodings.
The word ‘true’, if entered, would be taken to be the name of an HTTP content encoding, but there are none named ‘true’. The result of this setting would be to disable gzip compression permanently for *any* properly-functioning website.
Without compression, web surfing may be noticeably slower, but more worryingly it would increase the amount of data transferred when loading any page. (Data transfer is often limited to a fixed amount per month by ISPs; after exceeding their allowance a user may have their access restricted, or disabled until the next month or until further payment; some people using Pay-As-You-Go Internet access such as 3G which would be used up faster by changing this setting).
The error message mentioned in the blog post is a Firefox error message caused by a problem with the server or website code, not a problem with the browser. I’ve not noticed it myself on 1911census.co.uk, but could someone please tell me which pages trigger this so that I can investigate?
Thanks.
January 15th, 2009 at 7:47 pm
I think I now know what’s causing this. The explanation is very complicated, but the fix is simple:
Response.AppendHeader(”Vary”, “Accept-Encoding”);
If the ASP scripts on 1911census choose to serve compressed or uncompressed versions depending on the client’s Accept-Encoding header, they *SHOULD* send a Vary header in the response, _regardless_of_which_version_was_actually_served_. This is documented in RFC 2616 section 14.44:
“An HTTP/1.1 server SHOULD include a Vary header field with any
cacheable response that is subject to server-driven negotiation.”
If this is not done, some proxy servers may serve the uncompressed version of the page to clients who are capable of receiving compressed versions. Furthermore, in rare circumstances the proxy server may even tell the client that the data is compressed when it is not. Firefox, since version 3 I think, with default settings, shows the aforementioned ‘Content Encoding Error’ message when the declared encoding does not match the received data.
This would only affect a small number of visitors, who happen to be behind proxy servers that behave in a certain way. (Proxy servers are used by some ISPs, and often on shared internet connections eg. at work/universities/libraries.)
January 16th, 2009 at 9:48 am
Here is a fix for Internet Explorer:
In Tools, Internet Options, click the Advanced tab.
Under HTTP1.1 settings, untick the two boxes (”Use HTTP1.1″ and “Use HTTP1.1 through proxy connections”)
January 27th, 2009 at 10:05 am
Please fix your compression, it doesn’t work. All the fixes posted require users to tell their browsers to not support compression, so the uncompressed pages are sent. Your compressed pages aren’t readable!
My mother has paid money to access your site & can’t, without me disabling compression for every website she visits.
March 11th, 2009 at 1:37 pm
I am shocked that as of today (2 months later), this error is still outstanding. It’s particularly poor considering that the user will only see an error message for (what appears to be) the whole site, with no indication in human-readable terms of what the problem is.
The fixes above are useful for the technically capable, but as a web admin myself, I would never expect my users to have to resort to this kind of technical wizardry, and I wouldn’t expect them to cripple a useful feature in their browser just because I can’t be bothered to configure my server properly.
March 12th, 2009 at 2:06 pm
@Gary - it’s not affecting many users, hence it’s lower down the priority list than some other fixes and features.
March 18th, 2009 at 5:10 pm
This problem is very easy to reproduce by installing the Squid proxy server software (someone mentioned version 2, and I’m seeing the same in version 3), configuring a browser to use it, and attempting to visit 1911census.co.uk.
My earlier suggestion about the Vary header is probably not the real cause of this problem after all. I now think it’s due to the fact that Squid makes HTTP/1.0 requests, and not HTTP/1.1, which is more often the case. The server should not use chunked encoding in response to an HTTP/1.0 query; however the 1911census.co.uk server uses chunked encoding regardless.
Because a HTTP/1.0 client or proxy server does not understand chunk encoding, it will see the chunk headers (which are hex values) appearing in the middle of the compressed data, causing the error message above because it will not decompress.
As a quick test of this, you could try disabling gzip/deflate compression in response to any HTTP/1.0 query — the result should be renderable by a browser although you’d probably still see one or chunk headers at the start of the HTML and possibly elsewhere.
April 24th, 2009 at 2:57 am
I noticed that this is not the first time you write about this topic. Why have you chosen it again?
April 27th, 2009 at 1:44 am
It seems that we now have a definitive answer from our Technical team.
1911census.co.uk uses Microsoft IIS6 web servers, which when queried, always provide HTTP 1.1 encoded pages. Some proxy servers (e.g some versions of Squid) cannot process these as they only support HTTP 1.0. This means that if users are accessing the site via a network unable to process HTTP 1.1, they will get blank pages returned unless using a hack to bypass the proxy server.
Recommended fix: upgrade to a proxy server able to process HTTP 1.1 - unfortunately there is no option currently to make IIS6 return a 1.0 response (unfortunate but true). Squid 2.7 will support chunked headers.
May 10th, 2009 at 7:11 pm
Can I quote you in my report for school?
May 25th, 2009 at 12:57 am
My website is plagued with the “Content Encoding” problem also.
This issue only presents itself to the FireFox browser, my guess is FireFox is no longer the standard for properly rendering web pages.
Try google chrome instead.
September 22nd, 2009 at 5:06 pm
This message is a result of a poisoned cache.
How to solve it:
write in your browser: about:config ,and set this to false:
network.http.use-cache
Then try loading said site again. It will load.
Set it back to true, and the website fails to load, prompting the message.
Please spread the word to solve this problem quickly
November 21st, 2009 at 9:17 am
So what should a mere mortal do?
December 18th, 2009 at 3:41 pm
I think the configuration of this site is broken. Period. No other sites exhibit this problem whether they are using IIS6, compression or are being accessed via a squid proxy. I urge the webadmins of this site to review their web server configuration and to test with a browser running through a squid web cache. As an earlier poster pointed out, many if not all univeristies and libraries are likely to be pushing their users through a squid proxy server. Asking users to change their browser settings is just buck passing.
December 18th, 2009 at 6:12 pm
We provide internet access for 250 schools and 30 public libraries, non of which are currently able to access the site due to this issue with Squid. Please could someone take a look at this as a matter of urgency. Please feel free to contact me if you need anyone to test the service once reconfiguration has taken place. This is the only site our users are having issues with.