[PATCH] Correct Content-Type header values for archive downloads

Ry4an Brase ry4an-hg at ry4an.org
Mon Sep 20 23:14:01 CDT 2010


On Tue, Sep 21, 2010 at 12:57:43AM +0200, Dan Villiom Podlaski Christiansen wrote:
> On 20 Sep 2010, at 23:41, Ry4an Brase wrote:
> 
> >I've changed the .tar.gz and .tar.bz2 Content-Types to
> >application/x-gzip and application/octet-stream, restively.  Which
> >yields correctly named download artifacts.
> 
> Isn't ‘application/x-bzip2’ the correct MIME-type for BZip2? That's
> what I get from ‘file -I’ locally as well as what Wikipedia lists it
> as.[1]
> 
> [1] <http://en.wikipedia.org/wiki/BZip2>

I googled around and it looked like many folks were going with
application/octet-stream for .bz2 files, and Wikipedia says
application/x-bzip (no two).  However, I've found enough other sites
that agree with application/x-bzip2 that it seems right and only likely
to get more right.  IANA doesn't have gzip much less bzip2.

Below is the patch with bzip2 instead of octet-stream and an updated
comment.

# HG changeset patch
# User Ry4an Brase <ry4an-hg at ry4an.org>
# Date 1285012568 18000
# Node ID 10e3f0819f5de33d08479d4114f6c73ccf7ebe42
# Parent  d0a97814b7d7f7eb6790d00813848dfc9ea82193
Correct Content-Type header values for archive downloads.

The content type for both .tar.gz and .tar.bz2 downloads was
application/x-tar, which is correct for .tar files when no
Content-Encoding is present, but is not correct for .tar.gz and .tar.bz2
files unless Content-Encoding is set to gzip or x-bzip2, respectively.

However, setting Content-Encoding causes browsers to undo that encoding
during download, when a .gz or .bz2 file is usually the desired
artifact.  Omitting the Content-Encoding header is preferred to avoid
having browsers uncompress non-render-able files.

Additionally, the Content-Disposition line indicates a final desired
filename with .tar.gz or .tar.bz2 extension which makes providing a
Content-Encoding header inappropriate.

With the current configuration browsers (Chrome and Firefox thus far)
are registering the application/x-tar Content-Type and not .tar
extension and appending that extension, yielding filename.tar.gz.tar as
a final on-disk artifact.  This was originally reported here:
http://stackoverflow.com/questions/3753659

I've changed the .tar.gz and .tar.bz2 Content-Type values to
application/x-gzip and application/x-bzip2, respectively.  Which yields
correctly named download artifacts on Firefox, Chrome, and IE.

diff -r d0a97814b7d7 -r 10e3f0819f5d mercurial/hgweb/hgweb_mod.py
--- a/mercurial/hgweb/hgweb_mod.py	Mon Sep 20 23:42:23 2010 +0200
+++ b/mercurial/hgweb/hgweb_mod.py	Mon Sep 20 14:56:08 2010 -0500
@@ -276,8 +276,8 @@
                 yield {"type" : i, "extension" : spec[2], "node" : nodeid}
 
     archive_specs = {
-        'bz2': ('application/x-tar', 'tbz2', '.tar.bz2', None),
-        'gz': ('application/x-tar', 'tgz', '.tar.gz', None),
+        'bz2': ('application/x-bzip2', 'tbz2', '.tar.bz2', None),
+        'gz': ('application/x-gzip', 'tgz', '.tar.gz', None),
         'zip': ('application/zip', 'zip', '.zip', None),
         }
 

-- 
Ry4an Brase - http://ry4an.org/


More information about the Mercurial-devel mailing list