I have always had issues with Large file uploading with PHP.
I heard that Perl is an alternative and a reliable way of handling large file uploads.
or Is there a better way in php (using swfupload etc) to manage large file uploads.
Do you have any idea about this?
Thanks,
B2W 2011
There are 3 configuration options that affects file uploading in php, all of them in php.ini, and some of them configurable at runtime.
You should take care of:
**max_input_time** its the time a script could invest in parsing the input
**file_uploads should** be set to on, it determines if uploads are allowed at all or not
**upload_max_filesize** is the maximum size for the uploaded files
**post_max_size** since uploads are inside POST requests, you should raise this value at least to the value you specified in upload_max_filesize
After you change this settings in php.ini, remember to restart apache.
It is also adviced to remove the max execution time limitation with:
set_time_limit(0); at code level.
Aside from that, remember that if you upload large files, you should never put the content of the files directly inside a variable, you would run out of memory if you do it.
Normally when you disable the timeout limit using set_time_limit(0)it should not produce any errors.
How large?
I believe that if the file is too (hundreds of megabytes), perhaps use a service dedicated to this (S3/DropBox, etc)?
Perl is an interpreted server-side language that runs on top of the web server, just like PHP, you switching languages is unlikely to change anything.
Is there a better way? Since you don't say you what issues are, we can't suggest a way to fix them ;-)
Related
I wonder if and how it is possible to write a custom "file handler" (parsing a file and rendering it with bonuses) for Apache 2 in PHP? Files are text files, and they could be large, so I'm not thinking of loading them entirely in memory, but processing them line by line.
I'm comfortable with Java and other languages but still rookie in PHP; I chose PHP because it's light and especially deployable on every Apache-capable machine (even small NAS), and, well, I like PHP.
Thank you for your hints.
Its not possible to write a file handler in php.
However you could use the rewrite engine to redirect those files that you want to handle to a php script that, then, does the job.
the original file can be obtained from the server variables.
hi i wanted to know if uploading large files like videos ( over 200 mb - 1gb) from php is a good option after setting up the server configuration like max_post_size , execution time etc. The reason i ask this question is because i read some where that when a large file is uploaded , best practice is to break that file into chunks and upload it ( I think youtube does that). Do i need to use another language like python or C++ for uploading large files or is php enough. If i need to use another language can anyone please help me with reading material for that .
Thank you.
PHP will hold the entire file in memory while the upload is happening. That means that if you are uploading 5 files in parallel, then at the very most you will need 5GB+ of memory.
This can be done in PHP, and I have done this using a chunking method. There are several SO questions on this topic:
File uploads; How to utilize “chunking”?
Upload 1GB files using chunking in PHP
But my personal preference is to use plupload. It is a very complete cross-platform (JS, Flash, Silverlight) upload script with a nice PHP code sample to handle chunking.
Its not only PHP to be considered for large file uploads. Your web server also need to support that, at least in nginx. I don't know how httpd handles that, but as you said splitting in chunks are viable solution. FTP is another option.
I'm developing a webapp in PHP, and the core library is 94kb in size at this point. While I think I'm safe for now, how big is too big? Is there a point where the script's size becomes an issue, and if so can this be ameliorated by splitting the script into multiple libraries?
I'm using PHP 5.3 and Ubuntu 10.04 32bit in my server environment, if that makes any difference.
I've googled the issue, and everything I can find pertains to PHP upload size only.
Thanks!
Edit: To clarify, the 94kb file is a single file that contains all my data access and business logic, and a small amount of UI code that I have yet to extract to its own file.
Do you mean you have 1 file that is 94KB in size or that your whole library is 94KB in?
Regardless, as long as you aren't piling everything into one file and you're organizing your library into different files your file size should remain manageable.
If a single PHP file is starting to hit a few hundred KB, you have to think about why that file is getting so big and refactor the code to make sure that everything is logically organized.
I've used PHP applications that probably included several megabytes worth of code; the main thing if you have big programs is to use a code caching tool such as APC on your production server. That will cache the compiled (to byte code) PHP code so that it doesn't have to process every file for every page request and will dramatically speed up your code.
I allow PDF files to be uploaded to my site (PHP).
I would like to offer the ability to also allow .zip files which contain PDF files in directories so it is easier for users to simply zip a directory and upload one file instead of uploading multiple zip files individual.
For those of you who offer a .zip file upload feature to your (PHP) website, what are the technical, security, and other issues you have faced?
Be careful how you unpack the zip, you could find yourself consuming far more resources than you expected. Perhaps some setrlimit(2) resource limits before unpacking would be wise.
The unzip(1) utility has several nice safety features built in; the -^ command line option turns off control-character filtering, so make sure you don't touch this :) and the -: command line option allows stupid pathnames like ../../../../etc/passwd. Make sure you're on at least version 5.50, so that those stupid pathnames are forbidden by default. (And don't use that command line option. I mention the options just so you can more easily find the documentation for them. :)
If you use an API, make sure it has options to prevent both kinds of silly filenames.
Assuming the .zip gets unpacked eventually you would have to make sure the directory they get unpacked in is unreachable by the the clients' browsers (with .htaccess or by placing it outside the web root directory), and even in that case I'd still monitor the contents of the unpacked .zip to make sure they didn't contain anything that might prove harmful (php or other files run by the server, html spoofs).
Another issue is i guess the upload_max_filesize set in php.ini, you can make sure it can be set big enough to suit your purposes before you start coding.
edit: also read sarnold's answer ;)
AFAIK, php can handle zip files pretty efficiently. Difficulties/Issues that I can think of is, while accessing the file where We need to extract the zip first, and then retrieve the actual needed file. Due to that reason, extracting a zip, might consume additional amount of server time, depending on the size of the file itself.
Where As, during uploads, I do not suppose there is any difficulties or issues specially emphasized on zip types.
My friend asked me to update a PHP application that his company uses. I found out that the application uses .ini extension for DB configuration file. The file contains DB host address, username, and password!!. The problem is that I can access the file on web-browsers.
I am trying to understand why. Is there any particular reasons to use a regular php file with .ini extension??? I just don't get it.
Readability is one of the main reasons I've used ini filies for php script configs in the past. People who are not coders have run into an ini file at least once before, and can understand what it is much easier than even a simple php file.
The issue of ini files being readable by everyone can be prevented by server side configuration, or even better, by simply adding a single line of code inside a comment line at the top of the file.
That way php will output an 'Direct access forbidden' when the file is accessed via a browser, and the ini file will continue to function as before.
You can use Zend_Config_Ini. It is comfortable and easy. Just simply do not put config files where any user can reach them (for example public_html).
INI files are just one way of dealing with configuration, perhaps the developer came from a Windows-developing background and used whatever he was familiar with :). Besides, PHP offers a convenient way of parsing INI files through the parse_ini_file function.
You'll want to make sure the .INI file is not accessible from the web though. Move it below the docroot so your PHP script can still access it, but random browsers cannot.
For what it's worth, PHP has traditionally used php.ini to configure PHP. So maybe it's some kind of legacy thing?
Seems like this is just former programmer's wish to use different file type for configuration. If there is no other uses for this file, rename it to *.php and forget it. If not, configure webserver to parse ini as php or, better, move it to directory, not reachable from web-server.