tests/test-mactext

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 > unix2mac.py <<EOF
import sys

for path in sys.argv[1:]:
    data = file(path, 'rb').read()
    data = data.replace('\n', '\r')
    file(path, 'wb').write(data)
EOF

cat > print.py <<EOF
import sys
print(sys.stdin.read().replace('\n', '<LF>').replace('\r', '<CR>').replace('\0', '<NUL>'))
EOF

hg init
echo '[hooks]' >> .hg/hgrc
echo 'pretxncommit.cr = python:hgext.win32text.forbidcr' >> .hg/hgrc
echo 'pretxnchangegroup.cr = python:hgext.win32text.forbidcr' >> .hg/hgrc
cat .hg/hgrc
echo

echo hello > f
hg add f
hg ci -m 1
echo

python unix2mac.py f
hg ci -m 2
hg cat f | python print.py
cat f | python print.py