9

I am quite surprise to find the above-mentioned error in my error log because I thought I have already done the necessary work to catch the error in my PHP script:

if ($_FILES['image']['error'] == 0)
{
 // go ahead to process the image file
}
else
{
 // determine the error
 switch($_FILES['image']['error'])
 {
  case "1":
  $msg = "Uploaded file exceeds the upload_max_filesize directive in php.ini.";
  break;
  ....
 }
}

In my PHP.ini script, the relevant settings are:

memory_limit = 128M
post_max_size = 3M
upload_max_filesize = 500K

I understand that the 3M is equivalent to 3145728 bytes and that this is what that is triggering the error. If the file size is above 500k but less than 3M, the PHP script would be able to run as per normal, issuing the error message in $msg as per case 1.

How do I catch this error instead of letting the script terminate abruptly with a PHP warning when post size exceeds post_max_size but still well within the memory limit? I have looked at similar questions here, here and here, but couldn't find an answer.

user229044
  • 232,980
  • 40
  • 330
  • 338
Question Overflow
  • 10,925
  • 18
  • 72
  • 110

2 Answers2

15

Found an alternative solution that does not deal with the error directly. The following code is written by a software engineer Andrew Curioso in his blog:

if($_SERVER['REQUEST_METHOD'] == 'POST' && empty($_POST) &&
     empty($_FILES) && $_SERVER['CONTENT_LENGTH'] > 0)
{
  $displayMaxSize = ini_get('post_max_size');

  switch(substr($displayMaxSize,-1))
  {
    case 'G':
      $displayMaxSize = $displayMaxSize * 1024;
    case 'M':
      $displayMaxSize = $displayMaxSize * 1024;
    case 'K':
       $displayMaxSize = $displayMaxSize * 1024;
  }

  $error = 'Posted data is too large. '.
           $_SERVER[CONTENT_LENGTH].
           ' bytes exceeds the maximum size of '.
           $displayMaxSize.' bytes.';
}

As explained in his article, when the post size exceeds post_max_size, the super global arrays of $_POST and $_FILES will become empty. So, by testing for these and by confirming that there is some content being sent using the POST method, it can be deduced that such an error has occurred.

There is actually a similar question here, which I didn't manage to find earlier.

Community
  • 1
  • 1
Question Overflow
  • 10,925
  • 18
  • 72
  • 110
1

You could check it with javascript first before the upload even takes place?

// Assumed input for file in your HTML
<input type="file" id="myFile" />


//binds to onchange event of your input field
$('#myFile').bind('change', function() {
    alert(this.files[0].size);
});

You can also pop a try catch around it:

try 
{
    if (!move_uploaded_file( 'blah blah' )) 
    {
        throw new Exception('Too damn big.');
    }
    // Can do your other error checking here...
    echo "Upload Complete!";
} 
catch (Exception $e) 
{
    die ('File did not upload: ' . $e->getMessage());
}
Fluffeh
  • 33,228
  • 16
  • 67
  • 80
  • 1
    The user may not have javascript enabled. – Question Overflow Jul 31 '12 at 11:25
  • +1 this might not fully solve the problem, but a good suggestion. – Raab Jul 31 '12 at 11:28
  • @QuestionOverflow Although true, but chances of that happening is 1 in a million as everything today needs JS to be enabled. Would be difficult to find someone with their JS disabled – asprin Jul 31 '12 at 11:28
  • @aspirin, I understand. But I am looking for a more reliable server side solution. You wouldn't want to do form validation client side only, would you? – Question Overflow Jul 31 '12 at 11:30
  • 1
    Yes, I can adopt try and catch block, but is this the way to go? Because I thought exceptions are triggered due to bad coding and I want to avoid bad coding. – Question Overflow Jul 31 '12 at 11:45
  • A to big `$_POST` size does not throw any Exception but raises a PHP Warning. You would have to provide your own error handler. See http://stackoverflow.com/a/1241751/246051 – fdomig Jul 31 '12 at 11:52
  • @fdomig Interesting, thanks for that link! Added too my +favs for further review. – Fluffeh Jul 31 '12 at 11:58
  • @fdomig, thanks for the link. So can anyone conclude that this error is unavoidable and therefore needs some error handling? – Question Overflow Jul 31 '12 at 12:04