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

Inefficient $response->file() should be removed #210

Open
ePirat opened this issue Jun 26, 2014 · 2 comments
Open

Inefficient $response->file() should be removed #210

ePirat opened this issue Jun 26, 2014 · 2 comments
Assignees
Milestone

Comments

@ePirat
Copy link

ePirat commented Jun 26, 2014

The $response->file() function should be removed or at least not be mentioned so heavily in the samples in the Readme. It is very bad practice to send files by just outputting them with php, php was not made for this and it should be preferred to redirect to the file using Location header.
It may work fine for small files, but it will make a lot of trouble for large files, especially with slow connections, since they will hit the max execution time of a php script. (This can be changed, but defaults to a very short time, about 30 seconds)

See "Why does readfile() exhaust PHP memory?" and "PHP readfile() and large downloads" and "Readfile() and large files"

@Rican7
Copy link
Member

Rican7 commented Jun 26, 2014

We could instead use a file buffer and stream to easily make it more efficient, but I do agree that the method shouldn't be there.

Its a relic from v1 and doesn't fit the v2 goals anyway.

I'll consider the options.

Thanks for your concern and comments! 👍

@Rican7 Rican7 added this to the 2.2 milestone Jul 20, 2014
@Rican7 Rican7 self-assigned this Jul 20, 2014
@seanmcn
Copy link

seanmcn commented May 4, 2015

@Rican7 Is this going to be removed or refactored? I was trying to use $request->file() with an external url and it doesn't work at all, if you're keeping it I might go ahead and refactor it myself and submit a pull request.

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

No branches or pull requests

3 participants