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 #31775 Undefined behavior when uploaded file > post_max_size
Submitted: 2005-01-31 11:23 UTC Modified: 2005-04-01 11:01 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: rudolf at softwares dot ch Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.3.9 OS: Windows XP Pro
Private report: No CVE-ID: None
View Developer Edit
 [2005-01-31 11:23 UTC] rudolf at softwares dot ch 
Description:
------------
I'm not sure if this is a documentation omission and/or a PHP bug:

I want to limit the size of files that can be uploaded to 8MB. I have set upload_max_filesize to 8MB and post_max_size to 10MB. memory_limit is not enabled.

When I upload a 9MB file, then $_FILES['myfile']['error'] is 1, as documented. When I upload a 14MB file, PHP writes nothing to stdout and writes the following to syslog:

PHP Warning:  POST Content-Length of 14171720 bytes exceeds the limit of 10485760 bytes in Unknown on line 0

The documentation doesn't say how PHP reacts when it uploads a file larger than post_max_size, but I would assume that it should not "give up," which is the behavior I'm experiencing.

Reproduce code:
---------------
<html>
<body>
<?php
	if ( $_POST['but_submit'] ) {
		printf("Got the submit!! error (%d) size (%d)",
			$_FILES['the_file']['error'],
			$_FILES['the_file']['size']);
	}

?>
<form method="post" action="fileupload.php" enctype="multipart/form-data">
<table class="form" border="0" cellpadding="0" cellspacing="0">
<tr>
	<td>File</td>
	<td>
		<input type="file" name="the_file" />
	</td>
</tr>
<tr>
	<td colspan="2">
		<input type="submit" name="but_submit" value="Submit" />
	</td>
</tr>
</table>
</form>
</body>
</html>

Expected result:
----------------
Unknown, since the documentation doesn't describe how PHP responds when the size of the uploaded file is greater than post_max_size.

Actual result:
--------------
A PHP warning written to syslog, and nothing written to stdout. See description above.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-31 11:27 UTC] derick@php.net 
The behavior is correct as POST data is received before the request is run, but upload_max_filesize is checked later.
 [2005-01-31 11:40 UTC] rudolf at softwares dot ch 
OK, but the documentation does not explain how this fairly common condition (an uploaded file > post_max_size) can be trapped.
 [2005-03-29 10:32 UTC] markusg at cants dot no dot spam dot de 
PHP also completely truncates the POST request, so you can't even tell there was one. Perhaps it would be more useful to process the incoming data up to the point where the post_max_size limit is reached, and then set a flag the programmer can check for.
 [2005-03-31 11:44 UTC] vrana@php.net 
Are you sure nothing is written to stdout? On the same environment, I experienced $_POST and $_FILES empty in case of data-size greater than post_max_size, but everything is written to stdout as usual.

Can you please give us a link to source of fileupload.php?
 [2005-03-31 12:00 UTC] vrana@php.net 
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.

"If the size of post data is greater than post_max_size, $_POST and $_FILES arrays are empty. You can track this condition various ways, e.g. by passing $_GET variable to the script processing the data, i.e. <form action="edit.php?processed=1"> and cheching this variable."
 [2005-04-01 10:24 UTC] rudolf at softwares dot ch 
Upon further testing, only Safari reacts to an uploaded file whose size is greater than post_max_size by saying it cannot connect to the server. Other browsers do indeed receive what is written to stdout.

Would it not be a more consistent solution if a new error code was defined for $_FILES['userfile']['error'] for this situation, instead of having to check for certain (not necessarily intuitive) states in the $_POST and $_FILES and $_GET arrays?
 [2005-04-01 10:33 UTC] vrana@php.net 
post_max_size is not necessarily bound to $_FILES. You can exceed it by sending e.g. big <textarea>. Thus $_FILES['userfile']['error'] is not the right place to report this error.
 [2005-04-01 11:01 UTC] rudolf at softwares dot ch 
You're right; it doesn't belong in $_FILES. But having to check the states of three arrays is also not the ideal way to check for the error.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Nov 17 17:00:01 2025 UTC