Skip to content
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

Open
zebracanevra opened this issue Jul 11, 2014 · 9 comments
Open

Provide file names #12

zebracanevra opened this issue Jul 11, 2014 · 9 comments

Comments

@zebracanevra
Copy link

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
Copy link
Author

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

@NuckChorris
Copy link
Collaborator

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
Copy link

qaisjp commented Apr 21, 2015

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

@NuckChorris
Copy link
Collaborator

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
Copy link

qaisjp commented Apr 21, 2015

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
Copy link
Collaborator

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

@qaisjp
Copy link

qaisjp commented Apr 21, 2015

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
Copy link
Collaborator

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
Copy link

qaisjp commented Apr 21, 2015

Oh, right, my bad. Fair enough!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants