note 75008 added to features.file-upload.errors

In reply to "svenr at selfhtml dot org" Since uploaded files are sent in the HTTP request body following the MAX_UPLOAD_FILE_SIZE file (that's why you need to put it before the file field in HTML), PHP can stop receiving the rest of the HTTP request body when the Content-Length header of that particular part of the request is more than the value of the MAX_FILE_SIZE field. Therefore, using the field renders a convenience, not a security fix, since the server can stop receiving the request body and start responding right after PHP has decided that the content-length is more (bytes) than allowed. This means that the client doesn't have to upload the entire body of the http-request, just to see an error appear. You can test this by using the field on a local server and for instance upload a 700MB iso or avi file or so. You will see that the server is quite quick in responding to say that the file is too large, even though the file hasn't been uploaded completely. Conclusively, MAX_FILE_SIZE isn't that useless after all (as upload_max_filesize is a PHP_INI_PERDIR setting) but you should be cautious to only use it as a convenience thing for the client, not as a security thing. ---- Server IP: 83.137.20.120 Probable Submitter: 213.84.170.161 ---- Manual Page -- http://www.php.net/manual/en/features.file-upload.errors.php Edit -- https://master.php.net/note/edit/75008 Del: integrated -- https://master.php.net/note/delete/75008/integrated Del: useless -- https://master.php.net/note/delete/75008/useless Del: bad code -- https://master.php.net/note/delete/75008/bad+code Del: spam -- https://master.php.net/note/delete/75008/spam Del: non-english -- https://master.php.net/note/delete/75008/non-english Del: in docs -- https://master.php.net/note/delete/75008/in+docs Del: other reasons-- https://master.php.net/note/delete/75008 Reject -- https://master.php.net/note/reject/75008 Search -- https://master.php.net/manage/user-notes.php