GET requests may contain an entity body
RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method -- it's nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via
POST/PUT/etc. Weird, right? Not a very good abstraction, is it?
Why a GET entity body is a bad idea
So what does the spec say about the GET method ... well:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe."
So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is only "SHOULD NOT" ... technically HTTP still allows a GET requests to result in an action that isn't strictly based around "retrieval."
Of course, from a semantic standpoint using a method named GET to perform an action other than "getting" a resource doesn't make very much sense either.
When a GET entity body is flat-out wrong
Regarding idempotence, the spec says:
Methods can also have the property of "idempotence" in that [aside from error or expiration issues] the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.
This means that a GET method must not have differing side-effects for multiple requests for the same resource. So, regardless of the entity body present as part of a GET request, the side-effects must always be the same. In layman's terms this means that if you send a GET with an entity body 100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must have the same result. This severely limits the usefulness of the GET method for sending entity bodies.
When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy of a method and its resulting side-effects.
This feature lets people upload both text and binary files. With PHP's authentication and file manipulation functions, you have full control over who is allowed to upload and what is to be done with the file once it has been uploaded.
PHP is capable of receiving file uploads from any RFC-1867 compliant browser.
Note: Related Configurations Note
See also the file_uploads, upload_max_filesize, upload_tmp_dir, post_max_size and max_input_time directives in php.ini
PHP also supports PUT-method file uploads as used by Netscape Composer and W3C's Amaya clients. See the PUT Method Support for more details.
Example #1 File Upload Form
A file upload screen can be built by creating a special form which looks something like this:
Send this file:
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 the file input field, and its value is the maximum filesize accepted by PHP. This form element should always be used as it saves users the trouble of waiting for a big file being transferred only to find that it
was too large and the transfer failed. Keep in mind: fooling this setting on the browser side is quite easy, so never rely on files with a greater size being blocked by this feature. It is merely a convenience feature for users on the client side of the application. The PHP settings [on the server side] for maximum-size, however, cannot be fooled.
Note:
Be sure your file upload form has attribute
enctype="multipart/form-data"otherwise the file upload will not work.
The global $_FILES will contain all the uploaded file information. Its contents from the example form is as follows. Note that this assumes the use of the file upload name userfile, as used in the example script above. This can be any name.
$_FILES['userfile']['name']The original name of the file on the client machine.
$_FILES['userfile']['type'] The mime type of the file, if the browser provided this information. An example would be "image/gif". This mime type is however not checked on the PHP side
and therefore don't take its value for granted.
The size, in bytes, of the uploaded file.
$_FILES['userfile']['tmp_name']The temporary filename of the file in which the uploaded file was stored on the server.
$_FILES['userfile']['error']The error code associated with this file upload.
$_FILES['userfile']['full_path']The full path as submitted by the browser. This value does not always contain a real directory structure, and cannot be trusted. Available as of PHP 8.1.0.
Files will, by default be stored in the server's default temporary directory, unless another location has been given with the upload_tmp_dir directive in php.ini. The server's default directory can be changed by setting the environment variable TMPDIR in the environment in which PHP runs. Setting it using putenv[] from within a PHP script will not work. This environment variable can also be used to make sure that other operations are working on uploaded files, as well.
Example #2 Validating file uploads
See also the function entries for is_uploaded_file[] and move_uploaded_file[] for further information. The following example will process the file upload that came from a form.
The PHP script which receives the uploaded file should implement whatever logic is necessary for determining what should be done with the uploaded file. You can, for example, use the $_FILES['userfile']['size'] variable to throw away any files that are either too small or too big. You could use the $_FILES['userfile']['type'] variable to throw away any files that didn't match a certain type criteria, but use this only as first of a series of checks, because this value is completely under the control of the client and not checked on the PHP side. Also, you could use $_FILES['userfile']['error'] and plan your logic according to the error codes. Whatever the logic, you should either delete the file from the temporary directory or move it elsewhere.
If no file is selected for upload in your form, PHP will return $_FILES['userfile']['size'] as 0, and $_FILES['userfile']['tmp_name'] as none.
The file will be deleted from the temporary directory at the end of the request if it has not been moved away or renamed.
Example #3 Uploading array of files
PHP supports HTML array feature even with files.
Pictures:
File upload progress bar can be implemented using Session Upload Progress.
daevid at daevid dot com ¶
13 years ago
I think the way an array of attachments works is kind of cumbersome. Usually the PHP guys are right on the money, but this is just counter-intuitive. It should have been more like:
Array
[
[0] => Array
[
[name] => facepalm.jpg
[type] => image/jpeg
[tmp_name] => /tmp/phpn3FmFr
[error] => 0
[size] => 15476
]
[1] => Array
[
[name] =>
[type] =>
[tmp_name] =>
[error] => 4
[size] =>
]
]
and not this
Array
[
[name] => Array
[
[0] => facepalm.jpg
[1] =>
]
[type] => Array
[
[0] => image/jpeg
[1] =>
]
[tmp_name] => Array
[
[0] => /tmp/phpn3FmFr
[1] =>
]
[error] => Array
[
[0] => 0
[1] => 4
]
[size] => Array
[
[0] => 15476
[1] => 0
]
]
Anyways, here is a fuller example than the sparce one in the documentation above: