you didn't understand: http://www.springfiles.com/download/3668/5 does send a HTTP 301 as response, if you want to get that file, you've to follow to that new location and request the file there with a range-request. So resources aren't wasted...

currently client + server implementation don't understand each other... one side has to be fixed, imo the server side. but i can't do anything, because i don't have access to springfiles, only to a dev-server.

jj wants accurate stats, but currently this is a bit broken because of this problem... let's wait what he says about this.

edit: i've fixed it on the dev-server it returns now the real url. jj please upload it to springfiles.com (https://github.com/springfiles/searchap ... api.module)

Licho, the files are not served by php, it's just a redirect, not a php- download script.

I dont like the approach to serve the direct url.
How can we check the used bandwidth for mirror owners?

But i will put abma's new code online, as soon as i am home (tonight)
That will solve all the problems.

ps. nice work abma!

uh... forgot to say, size and timestamp of the file is now returned, too.

Why the hell you care about used bandwith, i pay for the server and it has unlimited one. You cannot measure it this way anyway unless you process range headers correctly or measure it lower level.

I care about stable and reliable downloads for users..

And no Abma, you are mistaken, it does not return 302 for all URLs. Example:

Request



Response


If this isnt php served file then what is it jj and why it ignores range?

If we want bandwidth measured isn't that something that can be done via apache or some other method rather than php?

Abma has updated the code, so the problem with range headers will be gone.

Licho, i wanted to measure the dl stats because some mirrors have bandwidth limitations. Now lots of the traffic will be unmanaged which can be bad for particular mirrors. It has nothing to do with your server.

@licho: fixed, now only plain urls are returned

hm.. one issue i found is:

when watching the logs of springfiles, i saw some accesses like this:

GET /system/files/downloads/spring/games/Tech Annihilation.sd7 HTTP/1.1" 404 10643

this looks like some client's don't url-encode the request. maybe i should do this server-side in the xml-rpc result? (for example replace space with %20)

You could, but server has even more mirror sources so i should encode it there too.

And ideally clients should do that themselves but fastest fix is for me to url encode mirrors provided to lobbies.

Hey, nice work.

I don't like xmlrpc, but it is fine.
I implemented it in my Go package: https://github.com/Agon/go-slc/blob/mas ... archapi.go

Got a bot running which listens to following command:
"map mapname"
Prints out all mirrors which could be found.

Every springie autohost already does that but lists more than just those mirrors, because it has its own list as well.

jj, are you 100% sure nor

http://springfiles.com/system/files/dow ... egeDry.sd7

nor

http://springfiles.com/sites/default/fi ... egeDry.sd7

run using php?

I dont want ANY big downloads running through web technology. Make sure there are none please.

Yesterday your cron script killed server again and I don't want to waste extra resources

system/files/... is using php
sites/default/files ... isn't!

next addition: "description" field added,
this is a url to the download page + descriptions of a map/game, please use it!

the direct link is for autodownloaders, end-users should use the webpage.

@licho:
can you delete all urls from plasma starting with

http://springfiles.com/system
http://springfiles.com/download
http://www.springfiles.com/

i hope these are all invalid/duplicate urls...

They will be auto deleted when those becoe inalid

http://springfiles.com/system urls aren't invalid, they don't support the-range stuff.

the others are duplicates and should all return a 301 to http://springfiles.com but are valid, too.

Hmm then http://springfiles.com/system
should be removed from springfiles (if they are linked from somewhere).
I still see them used by the site itself.

drupal is using it, that can't be removed.