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.
Erreurs classiques
La variable MAX_FILE_SIZE ne peut pas spécifier une taille de fichier plus grande que la taille qui a été fixée par upload_max_filesize, dans le php.ini. La valeur par défaut est 2 megaoctets.
Si une limite de mémoire est activée, une plus grande valeur de memory_limit peut être nécessaire. Assurez-vous d'avoir défini une valeur pour memory_limit assez grande.
Si la valeur de max_execution_time est trop petite, le temps d'exécution du script peut excéder cette valeur. Assurez-vous d'avoir défini une valeur pour max_execution_time assez grande.
Note: max_execution_time affecte uniquement le temps d'exécution du script. Le temps passé sur l'activité qui apparaît en dehors de l'exécution du script comme les appels systèmes avec la fonction system(), la fonction sleep(), les requêtes sur les bases de données, le temps mis pour effectuer le téléchargement du fichier, etc. n'est pas inclus lors du calcul du temps maximal de l'exécution du script.
max_input_time définit le temps maximal, en secondes, au script pour recevoir les données ; cela inclut le téléchargement du fichier. Pour les fichiers multiples, ou les gros fichiers, ou encore pour les utilisateurs sur des connexions lentes, la valeur par défaut de 60 secondes peut être dépassée.
Si post_max_size est définit de façon trop faible, les gros fichiers ne pourront pas être téléchargés. Assurez-vous de définir post_max_size avec une taille suffisante.
Ne pas valider les fichiers que vous manipulez peut donner l'accès aux utilisateurs à des fichiers sensibles dans d'autres dossiers !
Attention : il semble que CERN httpd supprime tout ce qui est après le premier caractère dans l'entête MIME. Tant que c'est le cas, CERN httpd ne pourra pas effectuer de chargements de fichiers.
Du fait de la grande diversité des systèmes, nous ne pouvons garantir que les fichiers avec des noms exotiques (par exemple, ceux contenant des espaces) seront traités correctement.
Le développeur ne doit pas mixer les champs input normaux et les champs input de téléchargement dans une même variable (en utilisant un nom d'input comme foo[]).
Erreurs classiques
02-Oct-2007 12:22
09-Dec-2006 07: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)
20-Dec-2005 10: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...
22-May-2005 10: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.
11-Aug-2004 11: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.
21-Oct-2003 06: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!
09-Jun-2003 03: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.
28-Apr-2003 12: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
04-Feb-2003 05: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.
