When using the "Direct Download" manager, I expect it to issue a 301 redirect from "http://example.com/filebrowser/download/1" to "http://example.com/files/filename.ext". It doesn't do that. Instead it serves the file via PHP the same as if the "Private Download" manager was used. I have verified this using the http log files as well as the developer tools in Google Chrome.

Side question: why even do a 301 redirect at all for "Direct Downloads"? I was using a previous version of Filebrowser, where the links in the directory listings were to the public URI (e.g. "/files/filename.ext") rather than going through the Filebrowser URI first. This is far more efficient, so I'm wondering what the purpose of going through Filebrowser, and then issuing a 301 redirect to the right location is? (Ironically, the side question, in my particular use-case, is far more important than the actual bug for which I'm filing this. I need the URLs in directory listings to point to the actual server location, not to Filebrowser's ID only to be redirected.)

Comments

Yoran’s picture

Yoran commented
Status: Active » Fixed

Ok first there was a bug forcing "private" mode in every situations.
Second, the 301 story was added when some users asked for a generic way to write download managers. After a while I think my way of doing this was wrong. I changed that to a more easy way. A download manager is now just a way of building download URLS. A specific download manager module will now have to implements its own hook_menu and download stuff according to the URL it build for a specific file.
This way, "direct DLM" is now working as expecting building a simple direct download URL.

It's fixed in GIT/last dev release.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.