bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Networking: HTTP
P2
major
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Olivier Cahagne, Assigned: Darin Fisher)

Tracking

Trunk
mozilla0.9.2
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

17 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

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

Comment 2

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

Comment 3

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

Updated

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

Comment 4

17 years ago
really moving

Comment 5

17 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

17 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

17 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

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

Comment 10

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

Updated

17 years ago
Keywords: patch
r=bbaetz

Comment 12

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

Comment 13

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

Comment 14

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

Comment 15

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

Comment 16

17 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 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.