Code

Opened 4 years ago

Closed 16 months ago

Last modified 6 months ago

#15039 closed Bug (wontfix)

The current download link redirection breaks wget making Linux download inconvenient

Reported by: jonathanberger Owned by: aaugustin
Component: *.djangoproject.com 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

Description

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.

Attachments (0)

Change History (14)

comment:1 Changed 4 years ago by lukeplant

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 4 years ago by russellm

  • Component changed from Uncategorized to Django Web site
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 4 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 3 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 http://www.djangoproject.com/download/1.2.4/tarball/

(I had the same problem)

Last edited 3 years ago by iamit (previous) (diff)

comment:5 Changed 3 years ago by anonymous

  • Severity set to Normal
  • Type set to Bug

comment:6 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:7 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:8 Changed 2 years ago by aaugustin

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).

comment:9 Changed 2 years ago by aaugustin

  • Triage Stage changed from Accepted to Design 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/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...

comment:10 Changed 17 months ago by carljm

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 16 months ago by aaugustin

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

comment:12 Changed 16 months ago by aaugustin

  • Owner changed from nobody to aaugustin
  • Status changed from new to assigned
  • Triage Stage changed from Design decision needed to Accepted

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

comment:13 Changed 16 months ago by aaugustin

  • Resolution set to wontfix
  • Status changed from assigned to closed

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 6 months 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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.