php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #40387 MAX_FILE_SIZE erroneous.
Submitted: 2007-02-07 14:56 UTC Modified: 2007-03-23 17:37 UTC
Votes:2
Avg. Score:3.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: jon at hackcraft dot net Assigned:
Status: Closed Package: Documentation problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
 [2007-02-07 14:56 UTC] jon at hackcraft dot net 
Description:
------------
At http://www.php.net/manual/en/features.file-upload.php#features.file-upload.post-method and equivalent locations in other formats, it is stated that browsers take the value of a MAX_FILE_SIZE form field into account.

This information is repeated elsewhere on the web and in books, but appears to originate from the PHP documentation (it does not appear in terms of other server-side technologies).

There is nothing in any of the HTML, HTTP or related specs to indicate that this is the case (in particular RFC 1867 which introduced file uploads to HTML doesn't mention it, so it isn't even a case of a kludge that was mentioned in the first RFC and then dropped) nor does it make sense in the context of the HTML specs (there is nothing to indicate any relationship between that particular hidden input and the file input). The only statements about hidden fields I could find in any of them was warnings in the security considerations sections against user-agents basing any file-related operations on anything mentioned in a hidden field.

No browsers appear to perform this as an "extension". Indeed given that there are potentially other possible meanings for a hidden field with that name in an application handling several file uploads, it would have to be considered a design flaw any any did.

I submit that there is no such mechanism in mainstream browsers (if any at all) and indeed shouldn't be. Reference to it should be dropped from documentation.

I'd further suggest that since this idea has propagated from this documentation elsewhere that a note about it not working should to be added.

If a mechanism is required or desired for more rapidly handling this sort of file handling issue then it requires functionality to allow PHP to intercept streams being uploaded before request completion, which would be completely different to how this documentation suggest it should be dealt with, even if it was true.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-03-23 17:37 UTC] [email protected] 
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

"This is an advisory to the browser" deleted.
 [2010-12-16 17:17 UTC] mercator+bugs at gmail dot com 
I'd like to note that this bug has not yet been fixed.

Perhaps some of the misleading text was removed, but not all of it.

The documentation (online here: http://www.php.net/manual/en/features.file-upload.post-method.php, and the current XML source in SVN: http://svn.php.net/viewvc/phpdoc/en/trunk/features/file-upload.xml?view=markup&pathrev=303378) still mentions the following:

"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."

The 2nd and 4th sentence of this paragraph refer to the non-existent client-side properties of this hidden field, so they should be removed.

I also second Jon's suggestion that a note should be added here saying that it does *not* do anything on the client-side.

In fact, I'd suggest discouraging the use of this "feature", perhaps adding an example of how you can actually limit the file size reliably through e.g. $_FILES['userfile']['size'].

Even more, since it does nothing on the client-side, and can't be relied on on the server-side, I'd suggest removing the feature altogether. But then I suppose that's something for another bug report.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat May 03 17:01:27 2025 UTC