php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #44522 http upload max_limits and file above 2GB
Submitted: 2008-03-24 20:21 UTC Modified: 2013-09-13 11:39 UTC
Votes:108
Avg. Score:4.8 ± 0.6
Reproduced:99 of 101 (98.0%)
Same Version:29 (29.3%)
Same OS:50 (50.5%)
From: mail2lv at yahoo dot com Assigned: mike (profile)
Status: Closed Package: *Web Server problem
PHP Version: 5.2.5 OS: All
Private report: No CVE-ID: None
 [2008-03-24 20:21 UTC] mail2lv at yahoo dot com
Description:
------------
can anyone change the internal variables from int to long, i guess thats the reason why uploading files bigger than 2GB via http doesnt work. (yes, i tried post_max_size and upload_max_filesize bigger than 2048M).


Patches

uploads_larger_than_2g_HEAD_v2 (last revision 2012-03-26 03:59 UTC by jason at infininull dot com)
uploads_larger_than_2g_HEAD (last revision 2012-03-26 03:46 UTC by jason at infininull dot com)
uploads_larger_than_2g (last revision 2012-03-24 18:41 UTC by jason at infininull dot com)

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-04-24 09:12 UTC] robin at willowsv dot com
It will accept 2047M Anything bigger breaks post data completely. You 
can only use GET variables.
 [2009-12-09 20:40 UTC] tracey at archive dot org
we are using 64-bit ubuntu (jaunty and karmic) at archive.org, and php
v5.2.6 and v5.2.10 (respectively).  we are using fastcgi php-cgi
with nginx.

for us, with these 2 patches, we can get up to 8G posting to work
(haven't tried over 8GB 8-).

basically, they are about tracking the config setting/reading vars 
that are 32bits wide when they'd need 64bits, and similar for upload 
limit checking and reading.  

they prolly will not work with 32bit ubuntu immediately without some 
minor tweaking (since i started using long (8B on 64bit; 4B on 32bit) 
datatype and stuck with it instead of "long long" (8B on both)).  i'd 
be happy to try to extend the patches  to work on both 32bit and 64bit 
if there is interest.  (basically it took me awhile to figure these 
out and we are only running on 64bit so  i'd want an 
incentive/encouragement to do the extra work 8-)

http://www.archive.org/~tracey/downloads/patches/jaunty-64bit-post-
large-files.patch

http://www.archive.org/~tracey/downloads/patches/karmic-64bit-post-
large-files.patch

http://www.archive.org/~tracey/downloads/patches/jaunty-64bit-post-
large-files.patch-README.txt
 [2010-02-15 19:52 UTC] zaulychny at yahoo dot com
The same problem was faced by me. It seems that PHP stops if size of file is above 2Gb (i.e. signed int). 
Will someone fix this issue?
 [2012-02-22 09:30 UTC] noxxim at mail dot ru
Can someone add a patch for debian squeeze?
 [2012-02-23 10:14 UTC] jcabillot at gmail dot com
Do you plan to apply this patch ?
5.3 doesn't support file upload if the file is bigger than 2Gb.
It seem that 5.4 have the same limit.
 [2012-02-23 19:14 UTC] stas@php.net
-Package: Feature/Change Request +Package: *General Issues
 [2012-02-23 19:14 UTC] stas@php.net
It's probably too late for 5.4, but would be OK for trunk. The patch however 
needs to be cleaned up (no IGNORE vars, etc.) and changing signature for 
zend_atoi may not be safe if any code out there presumes it returns int (integer 
overflow). Also, no reason to use signed long there where we used unsigned long.
 [2012-02-23 19:15 UTC] stas@php.net
-Package: *General Issues +Package: *Web Server problem
 [2012-03-24 18:42 UTC] jason at infininull dot com
I was recently bitten by this bug too.  The patch needed a little updating for 
11.04 and I also found a couple of other issues.  1) Uploads only work if 
upload_max_filesize = 0 and 2) The $_FILES[*]['size'] value is an overflowed 
integer.  The attached patch fixes these issues.  I am currently in the process of 
re-rolling the patch against HEAD on master to get this in to upstream.
 [2012-03-26 04:02 UTC] jason at infininull dot com
I have re-rolled the patch against HEAD (b4d078f18c950a4bf7e136443586e348bd54f40c) 
and attached it to this request.
 [2013-04-19 09:37 UTC] scroogie at scroogie dot de
In my opinion this is quite an issue. We faced it at an intranet side yesterday.
Due to the cast to int at https://github.com/php/php-src/blob/master/main/rfc1867.c#L901 it also has weird side effects, like setting 4G will equal 0 and disable the size check (see https://github.com/php/php-src/blob/master/main/rfc1867.c#L1031), 5G equal 1G etc.
 [2013-04-19 20:21 UTC] azet at azet dot org
Could you please add this patch? It MIGHT make seem PHP less an embarrassing 
language than it is already.

Sincerely,
The Internet
 [2013-07-01 10:32 UTC] lang at b1-systems dot de
Newest Mailing List feedback applied.
Pull Request attached.
Please pull or comment in github or here.
 [2013-09-13 11:39 UTC] mike@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: mike
 [2013-09-13 11:39 UTC] mike@php.net
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Fixed in master on x86_64
 [2013-10-24 12:08 UTC] cweiske@php.net
The patch only supports files up to 4GiB. I failed to upload larger files and only got the following message on all browsers:

> PHP Notice:  Missing mime boundary at the end of the data for file 51.dat in Unknown on line 0,
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Nov 08 06:01:29 2024 UTC