Spiegazione dei messaggi di errore
Spotted whilst trying to test a file upload attachment script that worked on local PHP 5.1.2, but failed on customer's hosting website (PHP 4.1.2).
I hunted round and could not find this but $_FILES array
on older PHP (4.1.2) did not SET an errors element where as
later versions do, even if error is zero.
So if you check for errors, (as any good person should do)
put a caveat on checking errors to set a flag and to check
before any other name/type/size checks....
e.g.
$attachment = 0;
// ONLY process if attachment actually sent
if( isset( $_FILES[ 'attachment' ] ) )
if( empty( $_FILES[ 'attachment' ] ) )
$syserror[] = "Attachment is not valid.";
else
{
if( isset( $_FILES[ 'attachment' ][ 'error' ] ) )
{
if( ( $_FILES[ 'attachment' ][ 'error' ] == UPLOAD_ERR_NO_FILE ) )
$syserror[] = "Attachment failed to upload. Contact system administrator";
else
if( $_FILES[ 'attachment' ][ 'error' ] > 0 )
$syserror[] = "Attachment upload errored with error = ".$_FILES[ 'attachment' ][ 'error' ];
}
// Sometimes PHP 4 servers do not set an errors element so check if errored
// but proceed if no errors element
if( empty( $syserror ) && empty( $usererror ) )
{
$test = $_FILES[ 'attachment' ][ 'size' ];
if( $test == 0 || $test > $_POST[ 'MAX_FILE_SIZE' ] )
$usererror[] = "Attachment size is too large, max size is ".$_POST[ 'MAX_FILE_SIZE' ]." bytes.";
else
if( preg_match( $ban_ext, $_FILES[ 'attachment' ][ 'name' ] ) > 0 )
$usererror[] = "Attachment name is not valid.";
else
if( preg_match( $ban_type, $_FILES[ 'attachment' ][ 'type' ] ) > 0 )
$usererror[] = "Attachment type is not valid.";
else
$attachment = 1; // at this point attachment OK file system wise
}
}
Then in further processing note is $attachment set to 1..
Works well for me NOW!!!
--
Paul Carpenter
Much receding hairline later
Common Pitfalls
La voce MAX_FILE_SIZE non può specificare una dimensione del file maggiore di quella impostata dal parametro upload_max_filesize del file php.ini. L'impostazione di default è 2 Megabytes.
Se si è impostato un limite di memoria memory_limit può essere necessario ampliarlo. Occorre essere certi di impostare memory_limit alle dimensioni appropriate.
Se max_execution_time è impostato ad un valore basso, l'esecuzione dello script può eccedere tale valore. Ampliare max_execution_time ad un tempo sufficiente per l'upload.
Nota: max_execution_time influisce solo sul tempo di esecuzione dello script. Il tempo utilizzato per attività esterno allo script, tipo le chiamate di sistema system(), o la funzione sleep(), le query nei database, il tempo inpiegato nell'upload del file non è considerato nel computo del tempo di esecuzione dello script.
Avviso
max_input_time imposta il tempo massimo, in secondi, in cui lo script può ricevere dati; questo comprende l'upload di file. Per file di grandi dimensioni o molteplici file, o su connessioni lente, il valore di default 60 seconds può essere sforato.
Se post_max_size è impostato ad un valore troppo piccolo, non si può inviare file di grosse dimensioni. Impostare post_max_size alle dimensioni appropriate.
Non controllare il file su cui si sta operando potrebbe dare agli utenti accesso a informazioni sensibili contenute in altre directory.
Si noti che che il server CERN httpd sembra eliminare qualsiasi cosa a partire dal primo spazio nell'header mime content-type che riceve dal client. Fino a che questo si verificherà, il server CERN httpd non supporterà la possibilità di caricare file.
A causa della varietà di formati di directory, non si è in grado di garantire che nomi di file strani (ad esempio contenenti spazi) siano gestiti correttamente.
Un sviluppatore non può mischiare normali campi di input con campi di upload di file con lo stesso nome di campo (utilizzando nomi tipo foo[]).
add a note
User Contributed NotesCommon Pitfalls
paul at pcserviceselectronics dot co dot uk
08-Aug-2008 11:07
08-Aug-2008 11:07
anders jenbo pc dk
02-Oct-2007 06:22
02-Oct-2007 06:22
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-Dec-2006 02:02
10-Dec-2006 02:02
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)
rbemrose at gmail dot com
20-Dec-2005 05:07
20-Dec-2005 05:07
tjaart:
The HTTP/1.1 standard, section 4.2 says this about message headers:
"Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of LWS, though a single SP is preferred."
This can be interpreted in two ways:
1. You have to have at least one whitespace character between the header name and field value.
or
2. You can have no whitespace before the field value.
Either way, the standard recommends 1 space, and you already know that works...
tjaart at siam-data-services dot com
22-May-2005 04:27
22-May-2005 04:27
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://...)
===================================
<?php
if ($_POST['submit']=='Upload') {
// Process File and the redirect...
header("location: http://"..."/somewhere.php");
exit;
}
?>
<html><head></head><body>
<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">
</form>
</body></html>
===================================
This only happens if all of the following are true:
header("location:http://...) with no space
Form being processed has enctype="multipart/form-data"
Browser=IE
To fix the problem, simply add the space.
Hope this helps someone else.
amalcon _a_t_ eudoramail _d_o_t_ com
11-Aug-2004 05:35
11-Aug-2004 05:35
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.
morganaj at coleggwent dot ac dot uk
22-Oct-2003 12:53
22-Oct-2003 12:53
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
09-Jun-2003 09:59
09-Jun-2003 09:59
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.
sebastian at drozdz dot ch
28-Apr-2003 06:59
28-Apr-2003 06:59
It's important that the variable 'open_basedir' in php.ini isn't set to a directory that doesn't not includes tempupload directory
admin at creationfarm dot com
05-Feb-2003 12:16
05-Feb-2003 12:16
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.