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

Status: RESOLVED DUPLICATE of bug 205156

(Core :: Networking: HTTP, defect)

Description

[Aldo]

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.

Comment 1

[Steve England [:stevee]]

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.

Comment 2

[Uri Bernstein]

Attachment: 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.

Comment 3

[Gervase Markham [:gerv]]

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/

Comment 4

[Darin Fisher]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.. If merging should just override the Content-Disposition header, no?

Comment 6

[WADA:World Anti-bad-Duping Agency]

DUP of Bug 205156?

Comment 7

[Frankie]

*** This bug has been marked as a duplicate of 205156 ***