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.
#!/bin/sh
hg init
cat > .hg/hgrc <<EOF
[encode]
not.gz = tr [:lower:] [:upper:]
*.gz = gzip -d
[decode]
not.gz = tr [:upper:] [:lower:]
*.gz = gzip
EOF
echo "this is a test" | gzip > a.gz
echo "this is a test" > not.gz
hg add *
hg ci -m "test" -d "1000000 0"
echo %% no changes
hg status
touch *
echo %% no changes
hg status
echo %% check contents in repo are encoded
hg debugdata .hg/store/data/a.gz.d 0
hg debugdata .hg/store/data/not.gz.d 0
echo %% check committed content was decoded
gunzip < a.gz
cat not.gz
rm *
hg co -C
echo %% check decoding of our new working dir copy
gunzip < a.gz
cat not.gz
echo %% check hg cat operation
hg cat a.gz
hg cat --decode a.gz | gunzip
mkdir subdir
cd subdir
hg -R .. cat ../a.gz
hg -R .. cat --decode ../a.gz | gunzip