young Wed May 26 16:54:06 2004 EDT
Modified files:
/phpdoc/en/features file-upload.xml
Log:
cosmetic changes
http://cvs.php.net/diff.php/phpdoc/en/features/file-upload.xml?r1=1.74&r2=1.75&ty=u
Index: phpdoc/en/features/file-upload.xml
diff -u phpdoc/en/features/file-upload.xml:1.74 phpdoc/en/features/file-upload.xml:1.75
--- phpdoc/en/features/file-upload.xml:1.74 Thu May 20 18:40:42 2004
+++ phpdoc/en/features/file-upload.xml Wed May 26 16:54:06 2004
@@ -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 @@
</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 @@
<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 @@
</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 @@
</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 @@
</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 @@
</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 @@
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 @@
</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 @@
<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 @@
</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 @@
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.
