Diese Seite bei php.net
The PHP manual text and comments are covered by the Creative Commons Attribution 3.0 License © the PHP Documentation Group - Impressum - mail("TO:Reinhard Neidl",...)
Der mit MAX_FILE_SIZE eingestellte Wert kann nicht größer sein als der des ini-Parameters upload_max_filesize. Der Standardwert ist 2 Megabyte.
Ist memory limit aktiviert, könnte eine Erhöhung von memory_limit nötig sein. Stellen Sie sicher, dass der Wert von memory_limit groß genug ist.
Wenn max_execution_time zu kurz konfiguriert ist, könnte das Skript den Wert überschritten haben. Stellen Sie sicher, dass der Wert von max_execution_time groß genug ist.
Hinweis: max_execution_time beschränkt nur die Ausführungszeit des Skripts selbst. Jegliche Zeit die auf Dinge entfällt die außerhalb des Skripts selbst stattfinden, wie z.B. Systemaufrufe über die system() Funktion, sleep(), Datenbankabfragen und die für das Hochladen von Dateien benötigte Zeit werden bei der Bestimmung der Ausführungszeit nicht mit einbezogen.
max_input_time legt die maximale Zeit in Sekunden fest während der es einem Skript gestattet ist Eingaben zu empfangen. Diese beinhaltet auch die für das Hochladen von Dateien benötigte Zeit. Werden viele oder große Dateien übertragen oder ist die Verbindung zum Benutzer langsam so kann die Standardeinstellung von 60 Sekunden überschritten werden.
Ist post_max_size zu klein konfiguriert, können große Dateien nicht hochgeladen werden. Stellen Sie sicher, dass der Wert von post_max_size groß genug ist.
Nicht zu prüfen an welcher Datei Sie arbeiten kann bedeuten, dass Benutzer auf sensible Informationen in anderen Verzeichnissen Zugriff erhalten.
Beachten Sie, dass CERN httpd in dem vom Client erhaltenen Content-Type Mime Header alles nach dem ersten Whitespace wegzuschneiden scheint. Solange dies der Fall ist, unterstützt CERN httpd keine Dateiuploads.
Aufgrund der vielen möglichen Arten der Darstellung von Verzeichnissen können wir nicht garantieren, dass Dateien mit exotischen Namen (wie z.B. mit enthaltenen Leerzeichen) auch wirklich richtig verarbeitet werden.
Es ist nicht möglich für normale Formularfelder und Dateifelder die gleiche Formularvariable (wie z.B. foo[]) zu nutzen.
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:
<configuration>
</system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="314572800"/>
</requestFiltering>
</security>
</system.webServer>
</configuration>
The above setting will allow 300 MB of data to be sent as a request. Hope this helps someone.
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.
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.
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)
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...
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.
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.
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!
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.
It's important that the variable 'open_basedir' in php.ini isn't set to a directory that doesn't not includes tempupload directory
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.
Diese Seite bei php.net