view tests/test-parentrevspec.out @ 12570:a72c5ff1260c stable

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.

6:755d1e0d79e9 
5:9ce2ce29723a 3:a3e00c7dbf11 4:bb4475edb621 
4:bb4475edb621 1:5d953a1917d1 
3:a3e00c7dbf11 
2:befc7d89d081 
1:5d953a1917d1 
0:837088b6e1d9 

should work with tag/branch/node/rev
tip^: 5
default^: 5
755d1e0d79e9^: 5
6^: 5

some random lookups
6^^: 3
6^^^: 2
6^^^^: 1
6^^^^^: 0
6^^^^^^: -1
6^1: 5
6^2: abort: unknown revision '6^2'!
6^^2: 4
6^1^2: 4
6^^3: abort: unknown revision '6^^3'!
6~: abort: unknown revision '6~'!
6~1: 5
6~2: 3
6~3: 2
6~4: 1
6~5: 0
6~42: -1
6~1^2: 4
6~1^2~2: 0

with a tag "6^" pointing to rev 1
6^: 1
6^1: 5
6~1: 5
6^^: 3

with a tag "foo^bar" pointing to rev 2
foo^bar: 2
foo^bar^: abort: unknown revision 'foo^bar^'!