This bug is a successor of bug 35956. Now that pages with an HTTP Content-Encoding preserve that coding when being saved, the save-as dialog should really suggest a filename using the appropriate system naming conventions for that coding (e.g. append ".gz"). Related bugs are bug 31519 (same for content /type/) and bug 52282 (for viewing the saved files).

->mscott?

*** Bug 100530 has been marked as a duplicate of this bug. ***

*** Bug 100737 has been marked as a duplicate of this bug. ***

spam: over to File Handling. i have not changed the assigned developer [or the other fields for that matter], so if anyone realizes that a bug should have a more appropriate owner, go ahead and change it. :)

What's the status on this bug? I can't find a more relevant place for the problem I have. Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.1) Gecko/20020826 Any time I try to download a .tar.gz file mozilla tries to append ".tar" to the name, resulting in "fnord.tar.gz.tar" The server response includes: Content-Type: application/x-tar Content-Encoding: x-gzip but Mozilla ignores the Content-Encoding and suggests an extension based only on the Content-Type, even though the file has the "right" extensions already: .tar.gz This isn't just a slight inconvenience, it means it is impossible to open a tar.gz straight into an archiving tool such as winzip - because Mozilla passes the "suggested" filename to winzip, which then tries to open the gzipped file as a tar file, and fails. You have to choose to save the file, fix the filename, then launch winzip manually. If you frequently download .tar.gz files on windows, this is extremely annoying.

Aye. Is there anything wrong with concatenating content-type and content-encoding? Not that I know this section of the code, but seems trivial. Even if, say, the tpe was test/plain and encoding was x-zip, is there any OS that *wouldn't* understand foo.txt.zip ?

I don't think that example is realistic. zip is an archiver, so I don't think it would qualify as an encoding type the way gzip does.

I've seen x-zip used in several places for accept-encoding and content-encoding, and described as the zip algo (one pkzip uses). Just because it is both an archiver and a compressor doesn't disqualify it from being used to encode single files. I was using it as an extreme example, and I still think that most OSs would understand foo.txt.zip

Googling a bit, I think such applications of "x-zip" as you describe are in error. It looks like historically "x-zip" has been used to identify gzip before it was a "g" thang. That is, back in the day, the default extension for gzip was ".z" and the associated encoding type was "x-zip". I haven't yet found a page describing exactly when the change occurred; but I suspect the rationale for it was too-subtle difference between ".z" and ".Z" (Unix compress, "x-compress"). What this means is that the Right Thing for an application to do is to treat the encoding type "x-zip" as identical to "gzip". Note that while gzip and PKZip use the same algorithm, the two are not compatible since the former is strictly a file compressor and the latter is an archiver.

Interesting that they are the same algorithm - did not know that, since original "pkzip" algo (which of course pkzip ripped off), was open to all, with appropriate accredition. Might've been a non-commercial use requirement too. In any case, couldn't be changed to a gpl license, which I assume gzip uses. There'd be license conflicts. Like trying to rebundle OpenBSD code as GPL. Alright, so examples are... foo.txt.z and foo.txt.gz And I still think that any major OS can handle that nowdays.

What's the last known good version of Mozilla without the save extension fault ? I have users/clients who are very confused by this behaviour.

so... how does this bug relate to bug 90490?

Regarding comment 12. I'd say they relate identically? ;)