cosmetic changes

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@159748 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Alexander Voytsekhovskyy 2004-05-26 20:54:06 +00:00
parent 7c0b6b0f9f
commit aea1f55f43

View file

@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.74 $ -->
<!-- $Revision: 1.75 $ -->
<chapter id="features.file-upload">
<title>Handling file uploads</title>
@ -53,18 +53,18 @@
</para>
<para>
The "_URL_" in the above example should be replaced, and point to a PHP
file. The MAX_FILE_SIZE hidden field (measured in bytes) must precede
file. The <literal>MAX_FILE_SIZE</literal> hidden field (measured in bytes) must precede
the file input field, and its value is the maximum filesize accepted.
Also, be sure your file upload form has
<literal>enctype="multipart/form-data"</literal> otherwise the file
upload will not work.
<warning>
<para>
The MAX_FILE_SIZE is advisory to the browser, although PHP also checks
The <literal>MAX_FILE_SIZE</literal> is advisory to the browser, although PHP also checks
it. Changing this on the browser size is quite easy, so you can never
rely on files with a greater size being blocked by this feature. The
PHP-settings for maximum-size, however, cannot be fooled. You should add
the MAX_FILE_SIZE form variable anyway as it saves users the trouble of
the <literal>MAX_FILE_SIZE</literal> form variable anyway as it saves users the trouble of
waiting for a big file being transferred only to find that it was too
big and the transfer actually failed.
</para>
@ -218,7 +218,7 @@ print "</pre>";
</simpara>
<simpara>
If no file is selected for upload in your form, PHP will return
$_FILES['userfile']['size'] as 0, and $_FILES['userfile']['tmp_name'] as
<varname>$_FILES['userfile']['size']</varname> as 0, and <varname>$_FILES['userfile']['tmp_name']</varname> as
none.
</simpara>
<simpara>
@ -239,7 +239,7 @@ print "</pre>";
<para>
<variablelist>
<varlistentry>
<term><varname>UPLOAD_ERR_OK</varname></term>
<term><constant>UPLOAD_ERR_OK</constant></term>
<listitem>
<para>
Value: 0; There is no error, the file uploaded with success.
@ -247,7 +247,7 @@ print "</pre>";
</listitem>
</varlistentry>
<varlistentry>
<term><varname>UPLOAD_ERR_INI_SIZE</varname></term>
<term><constant>UPLOAD_ERR_INI_SIZE</constant></term>
<listitem>
<para>
Value: 1; The uploaded file exceeds the
@ -257,7 +257,7 @@ print "</pre>";
</listitem>
</varlistentry>
<varlistentry>
<term><varname>UPLOAD_ERR_FORM_SIZE</varname></term>
<term><constant>UPLOAD_ERR_FORM_SIZE</constant></term>
<listitem>
<para>
Value: 2; The uploaded file exceeds the <emphasis>MAX_FILE_SIZE</emphasis>
@ -266,7 +266,7 @@ print "</pre>";
</listitem>
</varlistentry>
<varlistentry>
<term><varname>UPLOAD_ERR_PARTIAL</varname></term>
<term><constant>UPLOAD_ERR_PARTIAL</constant></term>
<listitem>
<para>
Value: 3; The uploaded file was only partially uploaded.
@ -274,7 +274,7 @@ print "</pre>";
</listitem>
</varlistentry>
<varlistentry>
<term><varname>UPLOAD_ERR_NO_FILE</varname></term>
<term><constant>UPLOAD_ERR_NO_FILE</constant></term>
<listitem>
<para>
Value: 4; No file was uploaded.
@ -336,9 +336,9 @@ print "</pre>";
sensitive information in other directories.
</simpara>
<simpara>
Please note that the CERN httpd seems to strip off everything
Please note that the <productname>CERN httpd</productname> 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
it gets from the client. As long as this is the case, <productname>CERN httpd</productname>
will not support the file upload feature.
</simpara>
<simpara>
@ -347,7 +347,7 @@ print "</pre>";
</simpara>
<simpara>
A developer may not mix normal input fields and file upload fields in the same
form variable (by using an input name like foo[]).
form variable (by using an input name like <literal>foo[]</literal>).
</simpara>
</sect1>
@ -388,10 +388,10 @@ print "</pre>";
<varname>$_FILES['userfile']</varname>,
<varname>$_FILES['userfile']['name']</varname>, and
<varname>$_FILES['userfile']['size']</varname> will be
initialized (as well as in $HTTP_POST_FILES for PHP versions prior
initialized (as well as in <varname>$HTTP_POST_FILES</varname> for PHP versions prior
to 4.1.0).
When
<literal>register_globals</literal> is on, globals for uploaded
<link linkend="ini.register-globals">register_globals</link> is on, globals for uploaded
files are also initialized. Each of these will be a numerically
indexed array of the appropriate values for the submitted files.
</simpara>
@ -465,7 +465,7 @@ PUT /path/filename.html HTTP/1.1
</para>
<para>
This would normally mean that the remote client would like to save
the content that follows as: /path/filename.html in your web tree.
the content that follows as: <filename>/path/filename.html</filename> in your web tree.
It is obviously not a good idea for Apache or PHP to automatically
let everybody overwrite any files in your web tree. So, to handle
such a request you have to first tell your web server that you
@ -506,9 +506,9 @@ Script PUT /put.php
linkend="features.file-upload.post-method">POST-method</link>.
When the request ends, this temporary file is deleted. So, your
PUT handling PHP script has to copy that file somewhere. The
filename of this temporary file is in the $PHP_PUT_FILENAME
filename of this temporary file is in the <varname>PHP_PUT_FILENAME</varname>
variable, and you can see the suggested destination filename in
the $REQUEST_URI (may vary on non-Apache web servers). This
the <varname>REQUEST_URI</varname> (may vary on non-Apache web servers). This
destination filename is the one that the remote client specified.
You do not have to listen to this client. You could, for example,
copy all uploaded files to a special uploads directory.