Content Encoding Error when loading an URL in browser

apache-2.2compression

One particular page on our site – http://www.newint.org/issues/1979/10/01/ – gives a Content Encoding Error when loaded in a browser. In Firefox, it says:

"Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression."

Safari gives a similar warning, saying “cannot decode raw data”. I've Googled this but found nothing relevant. All our pages are served compressed, but this page is no different from the many others that work. When I fetch it with wget -s http://www.newint.org/issues/1979/10/01/ it seems to work fine, and the first lines of the resultant file are the same as those of other files that work in my browser:

HTTP/1.1 200 OK
Server: Apache
Cache-Control: max-age=3600
Expires: Mon, 11 Jul 2011 10:47:15 GMT
Vary: Accept-Encoding,User-Agent
Content-Type: text/html
Content-Length: 34445
Date: Mon, 11 Jul 2011 09:47:16 GMT
X-Varnish: 396024918
Age: 0
Via: 1.1 varnish
Connection: keep-alive


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Does anyone have any solutions or things I could test?

Best Answer

I finally found the problem - an Apache virtual include referred to a directory rather than a file. Hopefully it'll help someone else to know this can give the above error.

Related Solutions

Tomcat – HTTP compression in IIS 6.0 causing problems with certain users

Ok, I think we've figured it out...

On the client side, Squid 2.5 and earlier doesn't understand "Transfer-encoding: chunked", so it delivers each chunk as the entire client request. Since it's only 1 chunk of the entire compressed request, it's invalid data and can't be read by the browser. (Not sure if this is an issue with other proxies)

On the server side, IIS always sends chunked encoding for Dynamic Compression (since IIS doesn't cache application responses, it has to compress each response on the fly, hence the chunked encoding).

The only way we can think of to fix this is to completely disable compression for HTTP 1.0 clients and only compress for HTTP 1.1 responses. The drawback is that anyone behind a proxy that sends 1.0 requests won't get compressed data and the site will load 0.5 - 1 second slower for those users.

Changes made in the metabase.xml file:

<IIsCompressionSchemes            Location ="/LM/W3SVC/Filters/Compression/Parameters"
...
HcDoOnDemandCompression="TRUE"
HcNoCompressionForHttp10="TRUE"
...
</IIsCompressionSchemes>

If anyone has a better solution, please let me know!

Apache won’t serve images larger than ~2K

A few things you can try:

Try setting EnableSendfile off in the Apache config and restart (see Apache core documentation). Also try EnableMMAP off (see here for a issue very similar to yours).
When testing with a browser make sure the cache is cleared and/or force the image to be reloaded.
Test with a variety of file sizes and types. Is it just PNG files, all images, etc...? Narrowing in on what image size works and what doesn't might help in the end.
Try testing another web server (lighttpd, nginx, ...) and see if they exhibit the same behavior. This should tell you if the issue is Apache specific or something on the server/network itself.
Download files both remotely and locally and see if the response is any different.

Related Topic