Gzip content not properly displayed when using Content-Encoding: x-gzip

VERIFIED FIXED in mozilla0.9.2

Status

()

P2
major
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: wolruf, Assigned: darin.moz)

Tracking

Trunk
mozilla0.9.2
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
Mozilla: 20010613
OS: Win2k SP1

Steps to reproduce:
Load URL:
http://cvsweb.netbsd.org/
Result: garbage
Expected result: normal HTML page with links, etc.

Perhaps gzip is broken or recently broke ?

Sniffer shows these headers sent to the browser:
[...]
Content-Encoding: x-gzip\r\n
Vary: Accept-Encoding: x-gzip\r\n
[...]

Comment 1

18 years ago
This is an antidup of bug 35956.  I believe that the fix for that bug broke this.

Comment 2

18 years ago
The component should be Networking HTTP. I lack the power to change it.
(Reporter)

Comment 3

18 years ago
Changing component to Networking HTTP
Component: Browser-General → Networking: HTTP

Updated

18 years ago
Assignee: asa → neeti
QA Contact: doronr → benc

Comment 4

18 years ago
really moving

Comment 5

18 years ago
The problem here is that the server says
Content-Encoding: x-gzip

after mozilla said
Accept-Encoding: gzip,deflate,compress,identity

While the HTTP 1.1 spec says
Use of program names for the identification of encoding formats
is not desirable and is discouraged for future encodings. Their
use here is representative of historical practice, not good
design. For compatibility with previous implementations of HTTP,
applications SHOULD consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively.


-> darin
Assignee: neeti → darin
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

18 years ago
The following will fix it but is almost certainly the wrong way.
It works with this change.

diff -u -r1.21 nsHttpChannel.cpp
--- nsHttpChannel.cpp	2001/06/13 22:44:46	1.21
+++ nsHttpChannel.cpp	2001/06/14 18:36:58
@@ -338,6 +338,7 @@
     }
 
     const char *val = mResponseHead->PeekHeader(nsHttp::Content_Encoding);
+
if (val &&
((0==PL_strcasecmp(val,"x-gzip"))||(0==PL_strcasecmp(val,"x-compress")))) val+=2;
     if (val && PL_strcasestr(nsHttpHandler::get()->AcceptEncodings(), val)) {
         nsCOMPtr<nsIStreamConverterService> serv;
         nsresult rv = nsHttpHandler::get()->
(Assignee)

Comment 8

18 years ago
David: right, we need to do something like that.  I'd like to simply add a 
method to nsHttpHandler that checks for a valid encoding.  
Severity: normal → major
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2

Comment 9

18 years ago
Created attachment 38474 [details] [diff] [review]
A slightly cleaner fix
(Assignee)

Comment 10

18 years ago
Created attachment 38790 [details] [diff] [review]
simplified/cleaned-up patch
(Assignee)

Updated

18 years ago
Keywords: patch
r=bbaetz

Comment 12

18 years ago
Seeing this on Linux; chaning OS to All.
OS: Windows 2000 → All

Comment 13

18 years ago
I want this.  (s)r=me.

Comment 14

18 years ago
*** Bug 86500 has been marked as a duplicate of this bug. ***

Comment 15

18 years ago
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
(Assignee)

Comment 16

18 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
VERIFIED June 22 morning CVS build on linux
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.