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

go to bug id or search bugs for

Bug #14008 $_POST/$_FILES when uploaded file is too large
Submitted: 2001-11-10 09:12 UTC Modified: 2001-11-18 18:31 UTC
From: heyesr@php.net Assigned: sniper (profile)
Status: Closed Package: HTTP related
PHP Version: 4.0CVS-2001-11-10 OS: RHL 7.1
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: heyesr@php.net
New email:
PHP Version: OS:

 

 [2001-11-10 09:12 UTC] heyesr@php.net 
Version is 4.2.0-dev.

When using the following script:

<?php
print_r($_POST);
print_r($_FILES);
if($_POST['submit']){
	exit;
}else{
	
?>

<FORM ACTION="test.php" METHOd="POST" ENCTYPE="multipart/form-data">
	<INPUT TYPE="HIDDEN" NAME="hidden" VALUE="blah">
	<INPUT TYPE="FILE" NAME="fileupload">
	<INPUT TYPE="SUBMIT" NAME="submit">
</FORM>

<?php 
	}
?>

If an uploaded file is smaller than the limit, then it prints the stuff as expected, however if the uploaded file is too large, then the _POST is missing information and $_FILES is completely empty.

For example. If the file is ok, this is what I got printed:


Array
(
    [hidden] => blah
    [submit] => Submit Query
)
Array
(
    [fileupload] => Array
        (
            [name] => expat-1.95.2.tar.gz
            [type] => application/x-gzip-compressed
            [tmp_name] => /tmp/phpQg7diG
            [size] => 190316
        )

)

And if the file is larger than 2Mb, this is what's printed:


Array
(
    [hidden] => blah
)
Array
(
)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-11-10 09:18 UTC] hholzgra@php.net 
so what do you expect?

the file is to big, so it is rejected

and the submit button is most likely
placed after the file input in the form
so its data comes after the file data in
the post so its behind the limit, too ...
 [2001-11-10 09:42 UTC] heyesr@php.net 
> so what do you expect?
> 
> the file is to big, so it is rejected

It would be nice to get some sort of confirmation that the file was rejected and why, instead of having to guess.

> and the submit button is most likely
> placed after the file input in the form
> so its data comes after the file data in
> the post so its behind the limit, too ...

This is just plain wrong. What about other form data that comes after the file? If I'm to redirect the user back to the form because the file was too large, I don't want them to have to retype stuff unnecessarily.
 [2001-11-10 10:16 UTC] sniper@php.net 
I'll take care of this.

--Jani
 [2001-11-10 19:48 UTC] sniper@php.net 
Please try the latest CVS and let me know if this is good.
Also note that errors set are stored in $php_errormsg 
variable if you have track_errors=on in your php.ini.

It now also sets different types for the error:

2 /* Uploaded file exceeded upload_max_filesize */
3  /* Uploaded file exceeded MAX_FILE_SIZE */
4  /* Only partiallly uploaded */

Maybe the first 2 might be same?
And we propably should have some PHP land constants for these?
 [2001-11-13 11:20 UTC] heyesr@php.net 
As mentioned in irc, it segfaults now when a file is uploaded that's larger than max filesize. Recompiling with --enable-debug didn't help, this output in error_log:

Unknown(0) : Warning - upload_max_filesize of 2097152 bytes exceeded - file [fileupload] not saved
[Tue Nov 13 17:03:56 2001]  Script:  '/usr/local/apache/vhtdocs/dev/test.php'
---------------------------------------
zend.c(860) : Block 0x403E107D status:
Beginning:      Overrun (magic=0x646E657A, expected=0x7312F8DC)
[Tue Nov 13 17:03:56 2001] [notice] child pid 11117 exit signal Segmentation fault (11)

Backtrace produced this:

(gdb) run -X
Starting program: /www/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x40138b9c in memcpy () from /lib/i686/libc.so.6
 [2001-11-18 18:31 UTC] sniper@php.net 
This is fixed now.

--Jani
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Jan 15 11:01:31 2025 UTC