From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 BuildID: 2001062823 Although http requests automatically decode and display html.gz files, File -> Open and file:// both ask which helper application to use. Reproducible: Always Steps to Reproduce: 1. Enter a location of "file:///foo.html.gz" 2. Repeat with http://www.gnu.org/manual/gdb-4.17/html_mono/gdb.html.gz Actual Results: The local file does not decompress and display. The http'd file DOES decompress and display. Expected Results: The behavior should be identical: on the fly decompression and display.

The reason for this is that on servers that do this, they are sending back a header of either "Content-Encoding: gzip" or "Content-Encoding: x-gzip" along with a Content-Type: "text/html" or something so that the browser knows that it is a zip/gzipped html doc in this isntance. Obviously your local file system does not send back headers so the browser cannot know this. This is the correct behaviour, so I'm marking this as Invalid.

I thought we did some extension->file type mapping w/ file URLs...

There are some bugs related to the empty content type being auto-detected (see bug 57884, bug 64703, bug 89045) But .gz files don't have to contain a single HTML file. They can be multiple .html files, a tar archive, or really anything else that you can store on disk. It might be a nice RFE to detect what the contents of the .gz file is (not sure of the difficulty here, presumably not too difficult thoguh), and if it is only one file try to determine the content type based on that.

Also see bug 35956 - "File extension not changed but gzipped files expanded when saving"

changed to RFE.

RESOLVED/DUPE: found it in the big file: bug cleanup. *** This bug has been marked as a duplicate of 52282 ***

VERIFIED: file: URL verification cleanup.