Pomf icon indicating copy to clipboard operation
Pomf copied to clipboard

Provide file names

Open zebracanevra opened this issue 10 years ago • 9 comments

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 avatar Jul 11 '14 11:07 zebracanevra

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

zebracanevra avatar Jul 11 '14 12:07 zebracanevra

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.

NuckChorris avatar Jul 12 '14 01:07 NuckChorris

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

qaisjp avatar Apr 21 '15 18:04 qaisjp

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

NuckChorris avatar Apr 21 '15 18:04 NuckChorris

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.

qaisjp avatar Apr 21 '15 18:04 qaisjp

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

NuckChorris avatar Apr 21 '15 18:04 NuckChorris

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.

qaisjp avatar Apr 21 '15 18:04 qaisjp

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.

NuckChorris avatar Apr 21 '15 18:04 NuckChorris

Oh, right, my bad. Fair enough!

qaisjp avatar Apr 21 '15 18:04 qaisjp