234031 - broken parsing of xlen in gzip rfc 1952

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Mark Davis]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031130

the GZIP spec allows for a comment to be inserted. Files served with a comment
inline don't decompress in mozilla, firebird or netscape 7. Works in NC 4.7
though...

Reproducible: Always
Steps to Reproduce:
See:
ftp://swrinde.nde.swri.edu/pub/png/documents/zlib/rfc-gzip.html

The FCOMMENT flacg being set freaks out Moz

Comment 1

[Boris Zbarsky [:bzbarsky]]

We just use zlib to decompress.  Does zlib handle these comments?

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

maybe our zlib is too old? looking at our changelog, we seem to use 1.1.4 while
1.2.1 is current

Comment 3

[Mark Davis]

Some more info from our diagnosis: the bug is in nsHTTPCompressConv.cpp.
and here's a bug with handling the 'extra fields' option, too.  looks like
you're throwing away the low order bits of the XLEN stuff

Comment 4

[tenthumbs]

> Does zlib handle these comments?

Zlib actually implements rfc1950 so it's not the issue here.

Comment 5

[tenthumbs]

Attachment: untested patch

This should fix the XLEN issue.

Comment 6

[Andrew Hagen]

We have a patch on this bug without a request for review or superreview. The
patch is very short.

To the author of the patch: you can maybe get this approved for 1.7 if you get a
review and superreview. Guidelines for that are on Mozilla.org.

Comment 7

[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 8

[Christian :Biesinger (don't email me, ping me on IRC)]

has a patch, confirming

Comment 9

[Darin Fisher]

-> default owner

Comment 10

[Patrick McManus [:mcmanus]]

This patch has been lost for a decade - but its obviously right. I apologize for the gap.

1952 section 2.3 defines XLEN bytes of extra data if flg.extra is set.. and xlen is a 2 byte quantity (less significant byte first aka little endian, as is true in all of gzip multibyte quantities)

The existing code drops the least significant byte getting the xlen definition wrong.

Comment 11

[Patrick McManus [:mcmanus]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c23dc9a0c208

Comment 12

[Patrick McManus [:mcmanus]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=da41979e18cb

Comment 13

[Patrick McManus [:mcmanus]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0df40c58b0cce08083297698acc094fbf7a27c29
Bug 234031 - broken parsing of xlen in gzip rfc 1952 r=mcmanus

Comment 14

[Patrick McManus [:mcmanus]]

"thanks for the patch!" (I'm going with better late than never.)

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0df40c58b0cc