Closed Bug 124787 Opened 23 years ago Closed 21 years ago

http://ftp.mozilla.org incorrectly serves *.gz with MIME type application/x-macbinary rather than application/x-gzip

Categories

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

Product:
mozilla.org
Component:
FTP: Mirrors
Type:
task
Priority:
Not set
Severity:
trivial

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla7, Assigned: kveton)

References

(
URL
)

Details

(Whiteboard: [MIME-dmg.gz]) 

Trying to download a .gz file from http://ftp.mozilla.org/ and it's showing up
as text instead of downloading to a file.  Notice the Content-type header below.

[sage:~] phroggy% telnet ftp.mozilla.org 80
Trying 207.200.81.212...
Connected to komodo.mozilla.org.
Escape character is '^]'.
HEAD
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-macho-macosx-trunk.dmg.gz
HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 11 Feb 2002 04:41:45 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Sun, 10 Feb 2002 12:29:06 GMT
ETag: "48e3-115ece-3c666792"
Accept-Ranges: bytes
Content-Length: 1138382
Connection: close
Content-Type: text/plain
Content-Encoding: x-gzip

Connection closed by foreign host.
*** Bug 124786 has been marked as a duplicate of this bug. ***
I believe this is a problem with all default Apache installs. Note the
Content-Encoding.
What, IYO, is the correct Content-Type?

Please always specify actual and expected behavior!
Content-type: application/x-gzip
gzip is not a Content-Type, but a Content-Encoding.

The following comment is from my /etc/mime.types file (Debian):

###############################################################################
#
#  MIME-TYPES and the extensions that represent them
#
#  This file is part of the "mime-support" package.  Please send email (not a
#  bug report) to mime-support@packages.debian.org if you would like new types
#  and/or extensions to be added.
#
#  Note: Compression schemes like "gzip", "bzip", and "compress" are not
#  actually "mime-types".  They are "encodings" and hence must _not_ have
#  entries in this file to map their extensions.  The "mime-type" of an
#  encoded file refers to the type of data that has been encoded, not the
#  type of the encoding.
#
###############################################################################

I think that is self-explaining ...
OK, so a .tar.gz file would have a Content-Type: application/x-tar and
Content-Encoding: x-gzip.  Now, what's the appropriate Content-Type for a .dmg
file?  It's a disk image, to be mounted.  application/x-dmg would work in a
pinch; is there an official standard anywhere?
From the man page for hdid (which is the command-line tool provided with OS X
for mounting .dmg files, which incidentally will take a URL as well as a filename)

       While  it  is  not  directly related to hdid(1), informing
       your web server that '.dmg' (and  others)  are  extensions
       associated  with  the  MIME  type application/octet-stream
       will allow web browsers to download the files rather  than
       try  to  display them.  For apache, you add the extensions
       to the appropriate line in /etc/httpd/mime.types.

-> taking QA contact so I don't need to watch Dawn anymore. ;)
QA Contact: endico → imajes
*** Bug 139054 has been marked as a duplicate of this bug. ***
9 monyhs later...

I think this bug has been resolved.

http://ftp.mozilla.org/pub/mozilla/nightly/latest/MacMozilla-MachO.dmg.gz (and
any other .gz AFAICT) now sends type application/x-gzip

$ telnet ftp.mozilla.org 80
Trying 207.200.85.49...
Connected to ftp.mozilla.org.
Escape character is '^]'.
HEAD http://ftp.mozilla.org/pub/mozilla/nightly/latest/MacMozilla-MachO.dmg.gz
HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 04 Jan 2003 23:49:59 GMT
Server: Apache/1.3.26 (Unix)
Last-Modified: Sat, 04 Jan 2003 17:55:53 GMT
ETag: "ba869-e82b87-3e172029"
Accept-Ranges: bytes
Content-Length: 15215495
Connection: close
Content-Type: application/x-macbinary
Content-Encoding: x-gzip

Connection closed by foreign host.

It's not a MacBinary file, but this is certainly better than text/plain.
The content-type is specific to each [foo].gz sub-suffix.
Content-Type: application/x-macbinary is technically incorrect, but works for me.

FWIW, mozilla-i686-pc-linux-gnu-sea.tar.gz is sent as
Content-Type: application/x-tar
Content-Encoding: x-gzip
URL: http://ftp.mozilla.org/pub/mozilla/ni... → http://ftp.mozilla.org/pub/mozilla/ni...
Severity: normal → trivial
OS: All → MacOS X
Hardware: All → Macintosh
Summary: .gz files on http://ftp.mozilla.org/ have MIME type text/plain → mozilla.org - dmg.gz has MIME type application/x-macbinary
Whiteboard: [MIME-dmg.gz]
*** Bug 153387 has been marked as a duplicate of this bug. ***
OS: MacOS X → All
Hardware: Macintosh → All
Summary: mozilla.org - dmg.gz has MIME type application/x-macbinary → http://ftp.mozilla.org incorrectly serves *.gz with MIME type application/x-macbinary rather than application/x-gzip
Depends on: 223045
-> Scott

Somebody's still got the wrong mime type for dmg...

should be octet-stream, not macbinary.
Assignee: endico → kveton
Component: webmaster@mozilla.org → FTP: Mirrors
QA Contact: imajes → myk
I'm confused.  No one is sending macbinary ... this bug appears to be rather old
and doesn't pertain to the new mirror setup.  Unless its simply informational.
3 of the 4 ftp mirrors are serving correctly (enough), the last is sending
text/plain (see bug 223045).
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.