>>1
Yeah, it'll work fine as you described.
* All unleechable content (ie, anything over 100MB) is stored outside of the www tree.
* Access to content is mediated by a ``download'' script which temporarily symlinks (but does not serve) the desired content into the www tree (with a unique random identifier). It then redirects the client to the symlinked content with a Location header.
* Have a cron script remove all stale symlinks (ie, symlinks that are older than X minutes).
man find.
There's a couple reasons why you don't want to serve the files out directly through a scripting language, and it's not a matter of tying up a daemon like
>>4 suggests (because a daemon is still going to be tied up if the server services the request directly).
The big gotcha is that the web server is going to use the sendfile syscall (if your OS supports it) which your scripting language probably won't have access to. So your script has to read the file into memory in chunks, then dump the chucks out to the network. sendfile effectively offloads that process to the OS, and data gets dumped off the disk and onto the network.
The other reason is that there's a bunch of other random shit, like Range headers that you'll have to parse to get everything working right. If you don't handle those, your clients won't be able to use multiple streams or resume broken downloads (though arguably, the symlink system would make resuming broken downloads non-trivial for most of the shit people use).
>>7
You have to give away the file location if you don't want to have a script delegating the transfer (though most languages provide a sendfile function, where supported). In the situation above, you're actually giving away the location of a temporary symlink which gets deleted after X minutes.
Sage for newfags and their stupid ``DOWNLOAD FREE ANIME'' sites.