view tests/test-context.py @ 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.
author Ry4an Brase <ry4an-hg@ry4an.org>
date Mon, 20 Sep 2010 14:56:08 -0500
parents a1aad8333864
children bd23d5f28bbb
line wrap: on
line source

import os
from mercurial import hg, ui

u = ui.ui()

repo = hg.repository(u, 'test1', create=1)
os.chdir('test1')

# create 'foo' with fixed time stamp
f = open('foo', 'w')
f.write('foo\n')
f.close()
os.utime('foo', (1000, 1000))

# add+commit 'foo'
repo[None].add(['foo'])
repo.commit(text='commit1', date="0 0")

print "workingfilectx.date =", repo[None]['foo'].date()