Opened 8 years ago

Closed 6 years ago

Last modified 5 years ago

#15039 closed Bug (wontfix)

The current download link redirection breaks wget making Linux download inconvenient

Reported by: jonathanberger Owned by: Aymeric Augustin
Component: * Version: 1.2
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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

Actual behavior:
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.

Change History (14)

comment:1 Changed 8 years ago by 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 to do this.

comment:2 Changed 8 years ago by Russell Keith-Magee

Component: UncategorizedDjango Web site
Triage Stage: UnreviewedAccepted

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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

(I had the same problem)

Last edited 8 years ago by IAmIT (previous) (diff)

comment:5 Changed 8 years ago by anonymous

Severity: Normal
Type: Bug

comment:6 Changed 7 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:7 Changed 7 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:8 Changed 7 years ago by Aymeric Augustin

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

comment:9 Changed 7 years ago by Aymeric Augustin

Triage Stage: AcceptedDesign decision needed

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/$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...

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by Aymeric Augustin

The release process documents to put the target URL in

comment:12 Changed 6 years ago by Aymeric Augustin

Owner: changed from nobody to Aymeric Augustin
Status: newassigned
Triage Stage: Design decision neededAccepted

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

comment:13 Changed 6 years ago by Aymeric Augustin

Resolution: wontfix
Status: assignedclosed

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.

comment:14 Changed 5 years ago by 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

Note: See TracTickets for help on using tickets.
Back to Top