Closed Bug 523859 Opened 16 years ago Closed 15 years ago

Content Encoding Error : invalid or unsupported form of compression

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: asa, Unassigned)

References

Details

There are a few dozen bugs reported on this issue mostly resolved invalid, WFM, or sitting open. The suggestion to clear cache seems to be pretty common and fixes the issue for a single page that was consistently failing with this warning. My situation is different. I'm seeing this on many pages, and repeatedly but intermittantly. This only happens when I'm on a dial-up connection and I suspect that it is a result of some kind of partial download of the data that we barf on. With guidance, I can provide logs or other information. Seeing this on latest trunk nightly builds for the last couple of weeks but I don't think this is specific to my build but rather to my connection speed. Content Encoding Error The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. https://bugzilla.mozilla.org/buglist.cgi?&bug_id=,317073,318836,323577,324363,337901,341944,342119,348152,359283,366023,382526,385011,390889,405430,422941,429629,434119,435369,436468,437868,440407,440421,446549,450158,460818,469352,479215,484900,488438,493367,501422,501953,505748,506591,508162,521168
ctrl+F5 / shift+reload should also work. I agree, this is a bug in the cache and there a few reports from the last year and I've seen this only once myself.
A forced reload works for that one load, but the error comes back up pretty quickly. I can reproduce this at digg and techmeme and several other sites reliably on dial-up.
I was able to reproduce this bug today, at the Seymonkey-website. When calling http://www.seamonkey-project.org/releases/seamonkey2.0.1/ the following message was shown: Content Encoding Error The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. Please contact the website owners to inform them of this problem. Here are the request and response headers: GET /releases/seamonkey2.0.1/ HTTP/1.1 Host: www.seamonkey-project.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Range: bytes=0- If-Range: "3c29-b9d75ec0" Cache-Control: max-age=0 HTTP/1.x 206 Partial Content Date: Tue, 15 Dec 2009 09:26:34 GMT Server: Apache Content-Location: index.en.html Vary: negotiate TCN: choice Last-Modified: Sun, 13 Dec 2009 22:32:03 GMT Etag: "3c29-b9d75ec0" Accept-Ranges: bytes Content-Length: 15401 Content-Range: bytes 0-15400/15401 Keep-Alive: timeout=20, max=999 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 Content-Language: en Each new request resulted in the same message only holding shift and clicking reload fixed it.
Also had this one. Firefox 3.5.6: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 I got it while looking at http://commons.apache.org and http://commons.apache.org/lang/cobertura/index.html. Mac/Command R didn't help (ctrl R, shift R also didn't). http://www.apache.org didn't show the error, but did show a misrendered HTML page. Restarting Firefox didn't help. Emptying the cache fixed the issue.
I'm cross posting this comment on several of these Content Encoding bugs... We have had a similar issue with users of our website. The problem seems to involve Range responses that are gzip encoded. I used the httpfox plugin and noticed that every time the error appeared, the request included a Range and If-Range header, and the response was 206 Partial Content (even though I was hard-refreshing). I'm not sure if this is a bug in mod_deflate, if range responses shouldn't be compressed, or in how firefox handles these responses. To solve the problem we updated our apache config to disable Range requests using mod_headers, since compression seems to provide more value: RequestHeader unset Range early RequestHeader unset If-Range early Header unset Accept-Ranges
(In reply to comment #10) I've tried to reproduce it but I can't configure my Apache to use compression together with Content-Length header. That's necessary because Firefox issues if-range request only if Content-Length header is present in cached entry. So I'm curious if there is some proxy (normal or transparent) between you and the server. It would be great if someone could provide reliable steps to reproduce this bug or provide detailed logs, dumps, etc... Useful information is: - HTTP and cache log (NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,cache:5) - dump of TCP communication - status of the relevant cache entry (info from about:cache)
Yes, our site runs uses a Content Distribution Network, which serves as a transparent proxy for our public users. Similar If-range requests (using telnet) made to both the CDN and origin servers gave identical responses, except for header reordering. Regardless, our users are denied service when Firefox displays an error page instead of site content, so we've disabled Range requests for our site.
This has been an ongoing problem for at least a year now (there are about a dozen bugzilla bugs open on this, and a Google search will bury you in results). There doesn't seem to be any long-term solution, occasionally Ctrl-F5 helps but often it doesn't, and it comes and goes at random (I've occasionally had it at sites like google.com, which probably haven't got a genuine problem with content encoding). The only solution that works in most cases is to switch to another browser, but this is real pain if you're eight levels deep on some site that requires a login and you need to go through all that again in a second browser just to get past one page. Despite the fact that it sometimes does show up in other browsers, there's something specific to Firefox that intermittently (or actually way too mittently) causes this problem when no other browser has it. In pretty much every case where I've encountered it it was only Firefox that had a problem, another indicator of this is the fact that when it's reported in web forums one person will experience it and several others won't when they try the same site. I realise that an intermittent bug like this is going to be a real pain to diagnose, but it would be good to get it fixed if it can be reproduced.
This seems to be the result of broken servers and not a problem Firefox is going to fix so marking as wontfix.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Asa: I disagree because Gecko should throw away the cached data and don't cache corrupt data. Ask 100 Users about shift+reload and I bet 99 don't know it. It would be enough if the error page would clear the cached entry and the next normal reload would fix it. That would be enough for most users.
Another argument that points at this being a FF issue is that the exact same sites that FF has trouble with work fine with MSIE or Opera. In addition since this has cropped up at sites like Google, it's unlikely to be a problem with the server. If FF doesn't want to fix this, maybe the error message could be changed to tell people to switch to MSIE or Opera instead :-).
Your logic is broken. That it works with Opera and IE doesn't mean that this isn't a server issue. server means here the server, a proxy or a stupid LSP in your windows installation like a third party Firewall and I'm 100% sure that it's one of this things. The only problem here is that the broken http data shouldn't be cached.
Regardless of whether this is a server or browser issue, it still ends up being a broken user experience. Could firefox automatically remove the cached data that leads to this error, instead of forcing users to do so?
It would be interesting to hear if anything like this happens after bug #612135 landed - feel free to notify me if so.
This bug is still around in FF25.0.1. https://bugzilla.mozilla.org/show_bug.cgi?id=846141
You need to log in before you can comment on or make changes to this bug.