'Content-Encoding: gzip, gzip' shows strange characters instead of the page content.

RESOLVED DUPLICATE of bug 205156

Status

()

RESOLVED DUPLICATE of bug 205156
14 years ago
13 years ago

People

(Reporter: Bugzilla, Assigned: darin.moz)

Tracking

1.0 Branch
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.

Updated

14 years ago
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.

Updated

14 years ago
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/
(Assignee)

Comment 4

13 years ago
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?

Comment 7

13 years ago

*** 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.