[oe] RFC: encourage switch away from heanet.sf.net

[Rolf Leggewie]

Michael 'Mickey' Lauer wrote:
>> Instead they automatically 302 you now.
> 
> If that's true, then +1 from me.

It seems they do.  And a sample session I wanted to provide as proof 
apparently also revealed how they deal with the situation that a mirror 
does not have the file.  I post only the relevant lines here.

$ wget http://downloads.sf.net/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: 
http://downloads.sourceforge.net/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk 
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: 
http://ovh.dl.sourceforge.net/sourceforge/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk 
HTTP Anforderung gesendet, warte auf Antwort... 200 OK

302 twice, then 200 from ovh.  Download successful.

$ rm qpf-unismall-100_1.0.0-r0_all.ipk
$ wget http://downloads.sf.net/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: 
http://downloads.sourceforge.net/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk 
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: 
http://puzzle.dl.sourceforge.net/sourceforge/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk 
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: 
http://prdownloads.sourceforge.net/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk?download&failedmirror=puzzle.dl.sourceforge.net 
HTTP Anforderung gesendet, warte auf Antwort... 301 Moved Permanently
Platz: 
http://downloads.sourceforge.net/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk?download&failedmirror=puzzle.dl.sourceforge.net 
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: 
http://osdn.dl.sourceforge.net/sourceforge/gakusei/qpf-unismall-100_1.0.0-r0_all.ipk 
HTTP Anforderung gesendet, warte auf Antwort... 200 OK

302 twice to puzzle which does not have the file and thus 302's again to 
prdownloads.  There is an added attribute that this file failed for the 
mirror and I assume that downloads.sf.net will act on that information 
for future downloads.  prdownloads sets a 301, we get another 302 and 
then osdn answers the request.  In some cases quite a few hops but it 
seems to work.

Out of curiousity, I tested out what happens with files that are not on 
the sf.net network.  It seems that one of two things happens.  If heanet 
is the first mirror being redirected to and it cannot find the file, it 
will answer with a 404 itself.  Otherwise, if some other mirror is used 
first, prdownloads will redirect to osdn which will redirect again to 
prdownloads with &failedmirror=osdn.dl.sourceforge.net.  A 404 is the 
answer.