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

go to bug id or search bugs for

Bug #46527 Files are uploaded even if larger than upload_max_filesize and post_max_size
Submitted: 2008-11-09 09:25 UTC Modified: 2008-11-14 14:54 UTC
From: krudtaa at yahoo dot com Assigned:
Status: Closed Package: Unknown/Other Function
PHP Version: 6CVS-2008-11-09 (snap) OS: Win XP
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2008-11-09 09:25 UTC] krudtaa at yahoo dot com 
Description:
------------
If you try to upload file(s) to the server and the files are larger than specified in upload_max_filesize and post_max_size then it looks like the files are uploaded to the server.

I have tested this on a file that was 100M large and where upload_max_filesize and post_max_size where set to 55M.

I see that the time before the script is beeing loaded after submission is approx the same regardless if the uploaded files are larger or smaller than what is specified in upload_max_filesize and post_max_size.

It would be nice to see a fix for this issue, since I do not see why the server should use resources on uploading the file(s) if it does not meet the criteria set in upload_max_filesize and post_max_size.
I belive PHP should abort the upload immediately when the form is beeing submitted and that it should be possible to detect what the reason for the bailout was in the script.

I have tested Arnaud Le Blanc's "Upload progress in sessions" patch which can be found here:
http://wiki.php.net/rfc/session_upload_progress

When the filesize was to large both the files array is empty and the session variable created by Arnaud's "Upload progress in sessions" are not created.

I do not belive Arnaud's patch is the cause for this though, mainly because of the feedback in this thread:
http://pecl.php.net/bugs/bug.php?id=9330&edit=1

Hope someone can fix this ASAP both in the upcoming PHP 6.0 version as well as in next versions of PHP 5.3

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-11-09 19:21 UTC] lbarnaud@php.net 
If the size of the input sent by the client is larger than post_max_size, the POST handler just do not try to "parse" the posted data (which results in no upload hooks, empty $_POST, empty $_FILES, etc).

After the script is executed PHP may ensures that all POST data has been read. This avoids breaking the HTTP protocol (in case of keep-alive connections, etc).
 [2008-11-09 23:02 UTC] krudtaa at yahoo dot com 
lbarnaud wrote:
"After the script is executed PHP may ensures that all POST data has been read. This avoids breaking the HTTP protocol (in case of keep-alive
connections, etc)."

I still belive it should be possible to make sure the files are NOT uploaded before the script "bails out".

Why not give us, the users of PHP, the possibility to supply a hidden field in the form, if this hidden field is present, then PHP should not let the files be transferred to the server if they are to large, and the developer should be able to test if that was the case in order to act accordingly.....

Then it would not break any HTTP protocol and those who does not want the server to handle that extra load can use the hidden field to prevent it....
 [2008-11-10 00:05 UTC] lbarnaud@php.net 
> then PHP should not let the files be transferred to the server if they are to large

This is how PHP handles such cases currently. In case of post_max_size exceeded it does not read anything before the script bails out.

It just reads post data _after_ the script bails out (without saving anything to disk or memory), until the client closes the connection.

> the developer should be able to test if that was the case in order to act accordingly

If the request method == POST and you don't have any of your post variables set, post_max_size was exceeded.

> Then it would not break any HTTP protocol

If the connection is Keep-Alive enabled, and there is unread client data left on the connection, the next request will not work.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 02:01:29 2024 UTC