310729 - File with .xml as extension and .tar.gz in the filename isn't seen as xml, dispite of it's content.

Status: RESOLVED INVALID

(Firefox :: File Handling, defect)

Description

[Bram]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050911 Firefox/1.0.6 (Debian package 1.0.6-5)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050911 Firefox/1.0.6 (Debian package 1.0.6-5)

When the given file is loaded, it isn't seen as an XML file dispite it being
one. The tar.gz in the filename seems to produce this problem. Accessing the
same file but without the .tar.gz in the filename, will make firefox see it as a
normal XML file. Due to this wrong identification you are also unable to see the
content using view source.


Reproducible: Always

Steps to Reproduce:
1. Create a valid viewable xml file (file.xml)
2. Make a copy of this file with tar.gz in the filename (file.tar.gz.xml)
3. Compare the results of both files.
Actual Results:  
file.tar.gz.xml won't be seen as an XML file while file.xml will.

Expected Results:  
Both files should be handled equally, because the tar.gz is not the last extension.

The Mozilla 1.7.8 web browser doesn't show the same problem.

Comment 1

[Oren Nachman]

The problem lies in the way Firefox reads the filenames. As another example if
you go to http://www.starwreck.com/download.php and try to download the
high-quality movie without subtitles
(star_wreck_in_the_pirkinning_xvid.avi.torrent) Firefox is sure that the file is
an ".avi" file and will try to open it in whatever media player you have
installed - instead of sending it to BitTorrent.

Comment 2

[Mike Shaver (:shaver emeritus)]

The URL in the field above advertises that it has Content-Encoding: gzip, but
sends non-gzipped data, which is (correctly, IMO) treated as corrupt data.

Looks like something that has to be fixed on the sourceforge end.  Tempted to
mark INVALID, though I could imagine someone filing a focused bug for us to try
Content-Encoding: none if whatever decoding we have fails.

Comment 3

[Oren Nachman]

1. Asking Firefox to open c:\temp\test.avi.torrent will cause Firefox to
correctly attempt to save/open the file as a torrent file (even when referenced
via file://)
2. Asking Firefox to open http://localhost/test.avi.torrent on a local apache
server causes Firefox to claim that the file is a Video File.

I am trying to hunt down the cause of this - but file extensions seem to be read
in a hundred different places. Any tips?

Comment 4

[Phil Ringnalda (:philor)]

Oren: the place to start looking is "elsewhere." The only thing your problem has
in common with this bug is that both might be Apache bugs, or might be Apache
misconfigurations. The server in comment 1 sends |Content-Type: video/x-msvideo|
so we treat it as video/x-msvideo. If we looked at anything other than that
header, including the extension, it would be a bug.

Bram: as shaver said, your problem is that sourceforge is claiming your file is
gzipped when it isn't, and you'll have to take it up with them about whether
that's a bug in their server or a feature you don't like. Various old builds
mishandle it in various strange ways, but trunk builds correctly report a
compression error, which certainly seems more useful than IE's "um, it's a blank
HTML page" or Opera's "ignore the encoding error, and the stylesheet too."
Silently ignoring errors that IE doesn't handle usually isn't a good idea, but
you can file a Core/Networking:HTTP enhancement bug on falling back to
uncompressed if you think it's a good idea anyway. However, this clearly isn't
that "focused bug."

Comment 5

[Bram]

The above is true, I didn't notice this at first. There currently seems to be no
way to avoide this Apache mistake.

For those still reading this, here is some more information:
"wget -S" will show the request headers, containing the "Content-Encoding: x-gzip"
It is generated by the AddEncoding statements of mod_mime. More information can
be read here: http://httpd.apache.org/docs/1.3/mod/mod_mime.html#addencoding

And of course, everybody thanks for looking into this!