Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 338966 - Download script continues to refer to mirror after download is archived
Summary: Download script continues to refer to mirror after download is archived
Status: VERIFIED FIXED
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Servers (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: ---   Edit
Assignee: Eclipse Webmaster CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-04 13:42 EST by Konstantin Komissarchik CLA
Modified: 2011-03-08 02:10 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Komissarchik CLA 2011-03-04 13:42:20 EST 
When a download file is moved to the archive, invoking the download url with the "r=1" directive continues to re-direct to mirrors, which predictably do not have that file any more.

See the following link for example. If it works, try it a few more times. You will eventually get redirected to a mirror.

http://www.eclipse.org/downloads/download.php?file=/webtools/downloads/drops/R3.2.0/R-3.2.0-20100615235519/repos/wst-sdk-buildrepo-R-3.2.0-20100615235519.zip&r=1

Not including "r=1" seems to reliably reference the archives server.

http://www.eclipse.org/downloads/download.php?file=/webtools/downloads/drops/R3.2.0/R-3.2.0-20100615235519/repos/wst-sdk-buildrepo-R-3.2.0-20100615235519.zip

Why is this a big deal? Automated download scripts always use "r=1" directive to get automatically forwarded to a mirror. Having to change download URL (to not include r=1) after project is archived isn't viable as it requires consumers to track when projects move their downloads to an archive or risk their integration systems breaking. 

My expectation is that "r=1" directive be ignored for archived downloads.
Comment 1 Denis Roy CLA 2011-03-07 14:05:01 EST 
Fixed.
Comment 2 Konstantin Komissarchik CLA 2011-03-08 02:10:25 EST 
Thanks! I have verified.