nokonoko / Pomf

Simple file uploading and sharing, source for the now shut down site Pomf.se
MIT License
465 stars 98 forks source link

Provide file names #12

Open zebracanevra opened 9 years ago

zebracanevra commented 9 years ago

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.

zebracanevra commented 9 years ago

Hmm, in #1 you mention adding support for this via X-Sendfile, but it seems nothing has been done since :(

NuckChorris commented 9 years ago

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.

qaisjp commented 9 years ago

How about just a simple tag that works like this a.pomf.se/id?n=realname.zip

NuckChorris commented 9 years ago

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

qaisjp commented 9 years ago

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.

NuckChorris commented 9 years ago

Sticking a tag on the end achieves nothing, except maybe removing a database read. That would still have to go through PHP

qaisjp commented 9 years ago

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.

NuckChorris commented 9 years ago

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 X-HTTP-Accel/X-Sendfile to actually handle shipping the file, but there still needs to be something, whether PHP or whatever, before each download. PHP has a pretty high fixed cost per request, as it turns out, which means that every pomf download would be delayed a few hundred milliseconds while PHP boots the code, runs it, and responds. On files like images (a popular use of Pomf), this additional delay could really be noticeable.

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.

qaisjp commented 9 years ago

Oh, right, my bad. Fair enough!