gzip files expanded when downloaded via "save link as"

VERIFIED FIXED in mozilla0.9.8

Status

Core Graveyard
File Handling
P2
critical
VERIFIED FIXED
16 years ago
a year ago

People

(Reporter: Darin Fisher, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({dataloss})

Trunk
mozilla0.9.8
dataloss

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
gzip files expanded when downloaded via "save link as"

go to http://ftp.mozilla.org/pub/mozilla/nightly/latest/, and right click on a 
.tar.gz file.  select "save link as" and notice that the downloaded file has
been decompressed.  this happens because the code invoking the download has not set
nsIHttpChannel::SetApplyConversion(PR_FALSE) as it should when downloading files.

see nsStreamTransfer.cpp:152 for an example of how this works.
file handling.
Component: XP Apps → File Handling
->default owner, but punt as needed.
Assignee: pchen → law

Comment 3

16 years ago
I also noticed that when I use a proxy that the downloaded file is both
ungzipped and TRUNCATED. Is there a bug on that?

Comment 4

16 years ago
Japanese users reported this bug reproduced MacOS 9.2(2001122408
) and MacOSX(0.9.7). Platform and OS should be All/All.

Updated

16 years ago
Keywords: mozilla1.0
OS: Linux → All
Hardware: PC → All
This sounds like a bug in WebBrowserPersist itself...  Adding dataloss since the 
file is truncated.
Assignee: law → adamlock
Keywords: dataloss
Keywords: nsbeta1
QA Contact: sairuh → tever

Comment 6

16 years ago
The xpfe should be specifying PERSIST_FLAGS_NO_CONVERSION as a flag to the
webbrowserpersist object. See bug 108268
Assignee: adamlock → ben
nominating since this should be a simple fix for a dataloss bug....  Just add a 
flag setting at 

http://lxr.mozilla.org/seamonkey/source/embedding/components/ui/progressDlg/nsPr
ogressDlg.js#382 (right before the try/catch).

+   webBrowserPersist.persistFlags |=
+       Components.interfaces.nsIWebBrowserPersist.PERSIST_FLAGS_NO_CONVERSION;

(if I recall the syntax for getting to interface constants correctly).

I'd attach a patch if I had a tree...
Keywords: mozilla0.9.8

Comment 8

16 years ago
->critical
Severity: normal → critical
*** Bug 118041 has been marked as a duplicate of this bug. ***
Blocks: 115634
Blocks: 118320
No longer blocks: 118320
*** Bug 118320 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
Created attachment 63912 [details] [diff] [review]
patch to fix

Comment 12

16 years ago
That specifies "no conversion" all the time, right?

I think there might be a complication when saving a web page served up by a
server that is doing content-encoding.  There has always been some lurking bugs
about that (or similar) situation and we should try to squash that now.  I'll
have to go track down the discussion.

Maybe we just turn off encoding for non-text types?  Or only turn it off for
application/zip, etc.?
One thing is that Apache will serve up gzipped files as

Content-Type: application/x-gzip  (or application/gzip?)
Content-Encoding: gzip

which is, of course, wrong....  We should try to handle that case as we fix this. 
:(
(Reporter)

Comment 14

16 years ago
bz: that case is already handled internally by necko.  all we need to do is
ensure that necko is instructed to not apply content conversions.  see the top
of nsHttpChannel::ProcessNormal for code that handles apache.
Darin, would the "no conversion ever" patch do the right thing then?  If not,
under what conditions should the "no conversion" flag be set such that
gzip-encoded HTML is gunzipped but regular gzip files are not?
(Reporter)

Comment 16

16 years ago
if that's the behavior you want then you need to check for Content-Type and
Content-Encoding headers.  telling necko to not apply content conversions means
that necko will simply ignore the Content-Encoding header.  by default necko
honors a Content-Encoding header.  you can override this behavior in your
OnStartRequest handler.

Comment 17

16 years ago
Darin,

How does this interact with the cache?  Is the content in the cache unzipped, or
compressed?  If we ask for the data from the cache with no content encoding,
might we still get it uncompressed if it is fetched from the cache?
(Reporter)

Comment 18

16 years ago
the content in the cache is decoded per any transfer encodings specified by a
Transfer-Encoding header and encoded per any content encodings specified by a
Content-Encoding header.

this means that if a server sends a document with Content-Encoding: gzip, the
document in the cache will be compressed.

you have actually described a bug that existed in the old days... the compressed
state of a saved file used to depend on how it was originally fetched.  now, we
avoid any problems like that by writing the data to the cache before (possibly)
decoding an encoded document.

Comment 19

16 years ago
What is the relation between this and bug 35956 ?

Would it help people working on this to compare?

Comment 20

16 years ago
The checkin for bug 110135 made PERSIST_FLAGS_NO_CONVERSION a default persist
flag so it would be worth retesting now.

Even so, it's best for the client (xpfe) to be explicit and set the flags it
wants to use unless it doesn't care how the persist object saves something.
Fixed. Patch w/analysis in bug 120174. 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 22

16 years ago
Works ok in 0.9.8. Anyone wants to mark "VERIFIED" or to close?

BTW, I do understand that "Content-encoding: gzip" is wrong.
Do you guys know what is right? ": data"?
verified that we now never unzip, even for files for which we should.  I'll
address that in another bug...
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.