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.
reverting foo
changeset 2:4d9e78aaceee backs out changeset 1:b515023e500e
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
searching for copies back to rev 1
unmatched files in local:
bar
resolving manifests
overwrite None partial False
ancestor bbd179dfa0a7 local 71766447bdbb+ remote 4d9e78aaceee
foo: remote is newer -> g
updating: foo 1/1 files (100.00%)
getting foo
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
n 0 -2 unset foo
M foo
c6fc755d7e68f49f880599da29f15add41f42f5a 644 foo
rev offset length base linkrev nodeid p1 p2
0 0 5 0 0 2ed2a3912a0b 000000000000 000000000000
1 5 9 1 1 6f4310b00b9a 2ed2a3912a0b 000000000000
2 14 5 2 2 c6fc755d7e68 6f4310b00b9a 000000000000