If max_execution_time
is set too small, script execution may be exceeded by the value. Make
sure you set max_execution_time large enough.

Note:
max_execution_time only
affects the execution time of the script itself. Any time spent
on activity that happens outside the execution of the script
such as system calls using system(), the
sleep() function, database queries, time taken by
the file upload process, etc. is not included when determining the maximum
time that the script has been running.

Warning

max_input_time sets the maximum
time, in seconds, the script is allowed to receive input; this includes
file uploads. For large or multiple files, or users on slower connections,
the default of 60 seconds may be exceeded.

If post_max_size is set too
small, large files cannot be uploaded. Make sure you set
post_max_size large enough.

As of PHP 5.2.12, the
max_file_uploads configuration
setting controls the maximum number of files that can uploaded in one
request. If more files are uploaded than the limit, then
$_FILES will stop processing files once the limit is
reached. For example, if
max_file_uploads is set to
10, then $_FILES will never contain
more than 10 items.

Not validating which file you operate on may mean that users can access
sensitive information in other directories.

Please note that the CERN httpd seems to strip off everything
starting at the first whitespace in the content-type mime header
it gets from the client. As long as this is the case, CERN httpd
will not support the file upload feature.

Due to the large amount of directory listing styles we cannot guarantee
that files with exotic names (like containing spaces) are handled properly.

A developer may not mix normal input fields and file upload fields in the same
form variable (by using an input name like foo[]).

User Contributed Notes 11 notes

Note that, when you want to upload VERY large files (or you want to set the limiters VERY high for test purposes), all of the upload file size limiters are stored in signed 32-bit ints. This means that setting a limit higher than about 2.1 GB will result in PHP seeing a large negative number. I have not found any way around this.

The macintosh OS (not sure about OSx) uses a dual forked file system, unlike the rest of the world ;-). Every macintosh file has a data fork and a resource fork. When a dual forked file hits a single forked file system, something has to go, and it is the resource fork. This was recognized as a problem (bad idea to begin with) and apple started recomending that developers avoid sticking vital file info in the resource fork portion of a file, but some files are still very sensitive to this. The main ones to watch out for are macintosh font files and executables, once the resource fork is gone from a mac font or an executable it is useless. To protect the files they should be stuffed or zipped prior to upload to protect the resource fork.

Most mac ftp clients (like fetch) allow files to be uploaded in Macbinhex, which will also protect the resource fork when transfering files via ftp. I have not seen this equivilent in any mac browser (but I haven't done too much digging either).

FYI, apple does have an old utility called ResEdit that lets you manipulate the resource fork portion of a file.

I think this is actually a header problem, but it onlyhappens when doing a file upload.

If you attept a header("location:http://...) redirect afterprocessing a $_POST[''] from a form doing a file upload(i.e. having enctype="multipart/form-data"), the redirectdoesn't work in IE if you don't have a space betweenlocation: & http, i.e.header("location:http://...) vsheader("location: http://...)

A responce to admin at creationfarm dot com, Mac OS X and Windows running on a NTFS disk also uses a multi stream file system. Still only the data stream in transfared on http upload. It is preferable to pack Mac OS X files in .dmg files rathere then zip but the avarage user will find zip much easir and they are supported on more platforms.