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
cat > patchtool.py <<EOF
import sys
print 'Using custom patch'
if '--binary' in sys.argv:
print '--binary found !'
EOF
echo "[ui]" >> $HGRCPATH
echo "patch=python ../patchtool.py" >> $HGRCPATH
hg init a
cd a
echo a > a
hg commit -Ama -d '1 0'
echo b >> a
hg commit -Amb -d '2 0'
cd ..
# This test check that:
# - custom patch commands with arguments actually works
# - patch code does not try to add weird arguments like
# --binary when custom patch commands are used. For instance
# --binary is added by default under win32.
echo % check custom patch options are honored
hg --cwd a export -o ../a.diff tip
hg clone -r 0 a b
hg --cwd b import -v ../a.diff