295199 - Download file name is inconsistent

Status: RESOLVED FIXED

(mozilla.org :: FTP: Mirrors, task)

Description

[Howard Rogers]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: Bugzilla 2.18.1

The Bugzilla 2.18.1 download option has a url reference to  
http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.18.1.tar.gz  but 
when selected using Internet Explorer 6.0.2900 a file download dialogue panel 
presents the default filename as bugzilla-2.18.1.tar.tar  

The file when downloaded is in fact of the type .gz and NOT .tar and does then 
unzip and provide a valid tar file.

Reproducible: Always

Steps to Reproduce:
1. Click on web site url using IE
2. Observe dialogue and default file name

Comment 1

[Cameron]

Firstly, nothing to do with UMO.

Secondly, I am unable to replicate this bug. 

Comment 2

[alanjstr]

Depends on your local config and the MIMEtype being served.  Mine saves it as
bugzilla-2.18.1.tar.gz but Winzip knows how to handle them here.

Reassigning to default owner.

Comment 3

[Max Kanat-Alexander]

WORKSFORME on my Firefox/Linux machine, here. Does it happen every time you
click on the file, or only sometimes? ftp.mozilla.org is actually a bunch of
different mirror machines.

Comment 4

[Howard Rogers]

It happens every time.  In fact if you click on the url link above or repeated 
here http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.18.1.tar.gz on 
this web page the same file name with the .tar.tar extension of is given as 
default!  See a screen dump attached below. 

Comment 5

[Howard Rogers]

Attachment: The IE download confirmation panel

Comment 6

[Dave Miller [:justdave]]

This is a bug in IE.

The webserver is sending a mime type of application/x-tar with a
content-transfer-encoding of gzip (which is the correct way to do it).

IE is apparently choking on that.

Comment 7

[Dave Miller [:justdave]]

excuse the spam, moving this to the right place first

Comment 8

[Dave Miller [:justdave]]

Retrieving webtools/bugzilla-2.18.1.tar.gz
156.56.247.196                 application/x-tar
204.152.184.113                application/x-gzip
205.188.221.241                application/x-gzip
216.165.129.134                application/x-gzip
64.12.204.21                   application/x-gzip
130.207.108.135                application/x-gzip
130.239.18.137                 application/x-tar
130.239.18.142                 application/x-tar
130.239.18.165                 application/x-tar
130.239.18.173                 application/x-tar
149.174.36.116                 application/x-gzip
152.163.212.246                application/x-gzip

looks like Indiana and umu.se are the ones offering it that way.

But I still contend that IE is broken.

Comment 9

[Paul Querna]

While I do agree it is a bug in IE to present the filename in this manner, I
also believe that the mirrors are incorrect to serve it as fileype of x-tar.

I do not believe that sending it as content-type of x-tar with a
Transfer-Encoding of gzip is correct.  I believe this because you cannot
re-encode it and come out with the same file at the other side.  Eg, if apache
re-did the T-E, with a lower level gzip compresssion, it would result in a file
with a different MD5 sum.  

Since it is important to have the receiver of the file get the extact bits in
gziped form, it should not be sent with a T-E.  It should send the correct
Content-Type of application/x-gzip, with no Transfer-Encoding.

Comment 10

[Dave Miller [:justdave]]

ok, this should be fixed now.  the mirrors in question have switched off the
transfer encoding header for gzip files.