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

[Tatham Oddie]

I've just tested in IE8. All good.

--
Tatham Oddie
au mob: +61 414 275 989, us cell: +1 213 280 9140, skype: tathamoddie
If you're printing this email, you're doing it wrong. This is a computer,
not a typewriter.


-----Original Message-----
From: mercurial-devel-bounces at selenic.com
[mailto:mercurial-devel-bounces at selenic.com] On Behalf Of Mads Kiilerich
Sent: Tuesday, 21 September 2010 9:08 AM
To: Ry4an Brase
Cc: mercurial-devel at selenic.com
Subject: Re: [PATCH] Correct Content-Type header values for archive
downloads

  Ry4an Brase wrote, On 09/20/2010 11:41 PM:
> # HG changeset patch
> # User Ry4an Brase<ry4an-hg at ry4an.org> # Date 1285012568 18000 # Node 
> ID ee5cbed86833252ff9dabe34ba21c59b28207dc0
> # Parent  e0ee3e822a9acb8d14602abdaa76740734977f2c
> 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.
>
> 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.
>
> diff -r e0ee3e822a9a -r ee5cbed86833 mercurial/hgweb/hgweb_mod.py
> --- a/mercurial/hgweb/hgweb_mod.py	Mon Sep 20 22:29:13 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/octet-stream', 'tbz2', '.tar.bz2', None),
> +        'gz': ('application/x-gzip', 'tgz', '.tar.gz', None),
>           'zip': ('application/zip', 'zip', '.zip', None),
>           }
>

Has this been tested with both recent and reasonably ancient Internet
Explorers?

/Mads
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel at selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6398 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100920/7587829f/attachment.bin>