-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide file names #12
Comments
Hmm, in #1 you mention adding support for this via X-Sendfile, but it seems nothing has been done since :( |
Yeah we really need some infrastructure improvements. It bothers me greatly that we don't have this yet, but I can't really do it in PHP unless we switch to something crazy like HHVM to speed it up: it'd add like 200ms delay to each download :/ There's a lot of things I'd like to do but just don't have the time. |
How about just a simple tag that works like this |
That doesn't solve the original problem, that pomf needs something faster-to-first-byte than PHP/Zend. HHVM is probably an option if Neku can figure out how to deploy it, but otherwise it'll probably require something like Node or Go/Rust/other-esoteric-modern-language |
I thought the original problem was to make pomf.se serve correct filenames whilst maintaining the ability to have unique urls? The easiest way to solve this issue? Stick a tag on the end that kinda works. I don't see any need in dealing with the other stuff (I'm not very experienced with PHP myself, so I can't say how much of a performance improvement it will be) unless implementing this feature really does bog down the performance of pomf.se. |
Sticking a tag on the end achieves nothing, except maybe removing a database read. That would still have to go through PHP |
It achieves a user-friendly filename, which is the purpose of this issue, though. I'm sorry if I'm not getting the point here, please can you explain it to me? All I see is that pomf.se is written in PHP, there aren't any GH issues directly addressing performance issues, therefore trying to write low level hackery for something as simple as a filename seems very overpowered. |
The file downloads never touch PHP, they're served directly by Nginx. Any solution to adding filenames will require some "smart" component to be added in front of the downloads. Luckily, we can use To my knowledge, we've exhausted all options to optimize the Zend engine's startup costs at this point (since XCache is the biggest fruit) and will need to find another way forward. |
Oh, right, my bad. Fair enough! |
Currently if I upload something, I get a random 6 letter ID for my file, and then the extension is tacked on at the end.
I'd like to be able to upload a file with a specific name and then also download a file with the same name.
For example, if I upload "abc.zip", I currently get a URL like http://a.pomf.se/qwerty.zip
I propose a URL which includes the zip name, like http://a.pomf.se/qwerty/abc.zip (so it still uses the ID internally.)
The file would only be downloaded if the ID and the filename matches, so this method also adds another layer of security for files uploaded (although that's negligible, as there are 300 million possible combinations not including the file extension which is limitless)
I imagine you'd store the file on the disk as qwerty.zip but serve the file as abc.zip.
Another way could just be to still have a.pomf.se/qwerty.zip, and then have the download be abc.zip, but I think that when you share the file you also want the filename to be in the URL - the users consuming your service will expect it to be like that, and less confusion is better.
The text was updated successfully, but these errors were encountered: