User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.7.6) Gecko/20050306 Firefox/1.0.1 (Debian package 1.0.1-2) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.7.6) Gecko/20050306 Firefox/1.0.1 (Debian package 1.0.1-2) Opening http://www.flashartonline.com/ , I get a lot of strange chars. It looks like a gzipped file. Works correctly if you add a useless parameter at the and of the URL http://www.flashartonline.com/?x Reproducible: Always Steps to Reproduce: 1. open http://www.flashartonline.com/ 2. 3. Actual Results: I get a lot of strange chars. Expected Results: Show the page correctly. Also a firefox 1.0.2 Bug. It could be caused by a wrong server configuration, but with other Browser, it works.
Summary: shows strange characters instead of the page content. → shows strange characters instead of the page content.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050412 Firefox/1.0+ I also see the described behaviour but I suspect it's a mimetype problem or something.
Created attachment 180482 [details] HTTP headers HTTP request and (more importantly) response headers for the page. Notice "Content-Encoding: gzip, gzip" which is probably the problem (there should be only one "gzip", I think). However, IE seems to deal with this fine, so this might be a compatability issue.
Assignee: firefox → darin
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → 1.0 Branch
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
I don't think we do anything reasonable in response to a "Content-Encoding: gzip, gzip" response header. So, I think this bug is valid. It looks like this bug no longer shows up on www.flashartonline.com, but I bet we could come up with a testcase that would demonstrate the original problem. I did notice some repeated headers in my disk cache: Accept-Range: bytes, bytes ETag: "foo", "foo" A tcpdump of loading the toplevel page shows that those repeated headers do not appear in the response from the server, so I wonder if they aren't getting generated when we merge the response from a 304 (or 206) with a cached version of the page.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: shows strange characters instead of the page content. → 'Content-Encoding: gzip, gzip' shows strange characters instead of the page content.
Target Milestone: --- → Future
Hmm.. If merging should just override the Content-Disposition header, no?
DUP of Bug 205156?
*** This bug has been marked as a duplicate of 205156 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.