The current download link redirection breaks wget making Linux download inconvenient

[jonathanberger]

Expected behavior:
Typing in:
wget DOWNLOAD_LINK
will result in the tar.gz file saved to the current directory.

Actual behavior:
wget ​http://www.djangoproject.com/download/1.2.4/tarball/
results in "index.html" because of the redirect being performed on the download link. The only obvious way for me to download to Linux, was to first download using Safari on my Mac and then scp the file to Linux.

[Luke Plant]

wget correctly follows the redirection and downloads the file. The only problem is that it decides to call the file 'index.html', not 'Django-1.2.4.tar.gz', which is what browsers seem to do.

In theory it should be easy to fix, by adding a header like Content-Disposition: attachment; filename=django-1.2.4.tar.gz. However, I don't know how easy it will be to get lighttpd (which is serving media.djangoproject.com) to do this.

[jonathanberger]

Ah, I didn't even realize that file getting download was indeed the install file.

Given that downloading the Django project is probably one of the most important steps in someone using the framework and that many new users with varying skill levels will be performing the action, I'd still encourage finding a solution.

[IAmIT]

this will do the trick (use the -O option in wget)
I admit it's a workaround, but it works:

wget -O django124.tar.gz http://www.djangoproject.com/download/1.2.4/tarball/

(I had the same problem)

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

We'll eventually move the downloads from media.djangoproject.com to www.djangoproject.com, that'll be a good opportunity to fix this (if the problem doesn't disappear altogether).

[Aymeric Augustin]

In fact, this isn't related to having a separate media server. We're using django.contrib.redirects to provide clean URLs for release tarballs. Unfortunately redirecting through django.contrib.redirects triggers this problem.

Adding a Content-Disposition header, as suggested in the first comment doesn't work: wget still saves the file under index.html. Here's the nginx config I tried:

        location ~ /m/releases/(.+)/(Django-.+\.tar\.gz) {
            alias /home/www/djangoproject.com/src/media/releases/$1/$2;
            add_header Content-Disposition "attachment; filename=$2";
        }

---

Alternatives at this point:

• consider this a bug in wget => wontfix for this ticket.
• consider this a bug in django.contrib.redirects => I'm not convinced...
• stop using django.contrib.redirects => it's useful to be able to move files without breaking URLs; I just did that today.
• change the URLs to include a filename => this is something we could do for the future releases...

[Carl Meyer]

I think changing the URLs for future releases to include the filename at the end is the most sensible/compatible solution. It doesn't seem to me that much is gained by leaving it off.

[Aymeric Augustin]

The release process documents to put the target URL in setup.py: ​https://github.com/django/django/commit/e3296268de8f2c387c4155ae1b8d39bb109f265d#L0R162

[Aymeric Augustin]

URLs are now ​generated by the releases app. This isn't to fix for future releases, starting with 1.6.

[Aymeric Augustin]

I thought this would be trivial to fix, but in fact it isn't, because it requires reversing to a different pattern, depending on the version.

I've spent hours to find a workaround to what boils down to a bug in wget -- every other UA behaves properly; I give up.

[anonymous]

I've just had this problem whilst downloading directly to ubuntu server,

changed the index.html file to django.tar.gz by using

mv index.html django.tar.gz

and was then able to untar and instal