PHP 5.6.29 Released

Problemas Comuns

O item MAX_FILE_SIZE não pode assumir um tamanho de arquivo maior que o tamanho de arquivo configurado em upload_max_filesize no arquivo php.ini. O valor padrão é de 2 megabytes.

Se um limite de memória está ativo, um valor maior para o limite de memória no parâmetro memory_limit pode ser necessário. Tenha certeza de estabelecer um limite de memória grande o suficiente através do parâmetro memory_limit.

Se o tempo máximo de execução definido através do parâmetro max_execution_time for muito pequeno, a execução do script pode ultrapassar o limite de tempo. Tenha certeza de estabelecer um tempo máximo de execução grande o suficiente através do parâmetro max_execution_time.

Nota: o parâmetro max_execution_time somente afeta o tempo de execução do script em sí. Qualquer tempo gasto com atividades que aconteçam fora da execução do script como chamadas de sistema usando system(), a função sleep(), pesquisas em banco de dados, tempo gasto pelo processo de enviar um arquivo(upload), etc. não são considerados no momento de determinar o limite de tempo máximo de um script em execução.


O parâmetro max_input_time define o tempo máximo, em segundos, que é permitido ao script a receber entradas, isto inclui upload de arquivos. Para um arquivo grande, múltiplos arquivos ou usuários com conexões lentas, o padrão de 60 segundos pode ser ultrapassado.

Se o parâmetro post_max_size for muito pequeno, arquivos grandes podem não ser carregados. Tenha certeza de definir o parâmetro post_max_size grande o suficiente.

Desde o PHP 5.2.12, o parâmetro max_file_uploads controla o número máximo de arquivos que podem ser enviados em uma única requisição. Caso sejam enviados mais arquivos que o definido neste limite, então $_FILES interromperá o processamento de arquivos uma vez que o limite tenha sido atingido. Por exemplo, se o parâmetro max_file_uploads está definido como 10, então $_FILES nunca possuirá mais de 10 itens.

Não validar o arquivo que você está operando pode permitir que os usuários acessem informações sensíveis em outros diretórios.

Por favor note que o CERN httpd aparenta retirar tudo começando no primeiro espaço do cabeçalho(header) content-type mime recebido do cliente. Se for este o caso, CERN httpd não irá suportar o upload de arquivos.

Devido ao grande número de estilos de listagem de diretórios não podemos garantir que arquivos com nomes exóticos (como os que contém espaços) sejam manuseados corretamente.

Um desenvolvedor não deve misturar campos comuns de entrada input e campos de upload de arquivo na mesma variável de formulário (usando um nome de campo input como foo[]).

add a note add a note

User Contributed Notes 11 notes

adrien.nizon+phpnet at gmail dot com
3 months ago
[Editor's note: to be more precise, MAX_FILE_SIZE can't exceed PHP_INT_MAX before PHP 7.1.]

Please note that the field MAX_FILE_SIZE cannot exceed 2147483647. Any greater value will lead to an upload error that will be displayed at the end of the upload

This is explained by the related C code :
if (!strcasecmp(param, "MAX_FILE_SIZE")) {
    max_file_size = atol(value);

The string is converted into a long int, which max value is... 2147483647

Seems to be corrected since php-7.1.0beta3 (
amalcon _a_t_ eudoramail _d_o_t_ com
12 years ago
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.
dg at artegic dot de
7 years ago
In case of non-deterministic occurence of the UPLOAD_ERR_PARTIAL error:  The HTTPD (e.g. Apache) should respond with a 'Accept-Ranges: none' header field.
admin at creationfarm dot com
13 years ago
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.
sebastian at drozdz dot ch
13 years ago
It's important that the variable 'open_basedir' in php.ini isn't  set to a directory that doesn't not includes tempupload directory
tjaart at siam-data-services dot com
11 years ago
Took me a while to figure this one out...

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

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

if ($_POST['submit']=='Upload') {
// Process File and the redirect...
header("location: http://"..."/somewhere.php");
<form enctype="multipart/form-data" action="upload.php" method="POST">
    <input type="hidden" name="MAX_FILE_SIZE" value="20000">
    Your file: <input name="filename" type="file">
    <input name="submit" type="submit" value="Upload">

This only happens if all of the following are true:
header("location:http://...) with no space
Form being processed has enctype="multipart/form-data"

To fix the problem, simply add the space.

Hope this helps someone else.
Nirmal Natarajan
6 years ago
If using IIS 7.0 or above, the Request Filtering is enabled by default and the max allowed content length is set to 30 MB.

One must change this value if they want to allow file uploads of more than 30 MB.

Sample web.config entry:

                <requestLimits maxAllowedContentLength="314572800"/>

The above setting will allow 300 MB of data to be sent as a request. Hope this helps someone.
anders jenbo pc dk
9 years ago
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.
oliver dot schmidt at drehsinn dot de
10 years ago
If you want to use open_basedir for securing your server (which is highly recommended!!!) remember to add your tmp dir to the open_basedir value in php.ini.

Example: open_basedir = <your htdocs root, etc...>:/tmp

(Tested on gentoo Linux, Apache 2.2, PHP 5.1.6)
morganaj at coleggwent dot ac dot uk
13 years ago
Here is another that may make your upload fall over.  If you are using Squid or similar proxy server make sure that this is not limiting the size of the HTTP headers. This took me weeks to figure out!
tomcashman at unitekgroup dot com
13 years ago
For apache, also check the LimitRequestBody directive.
If you're running a Red Hat install, this might be set in /etc/httpd/conf.d/php.conf.
By default, mine was set to 512 KB.
To Top