Maintainers of any module that handles files always has the problem of the issue related to file upload sizes. One by one, solutions have been found to all, with the exception with max_post_size. Since PHP drops the entire $_POST array, AHAH requests fail to load the cached form and standard form submissions result in complete loss of all form data.

I'm have also had issues with this, but checks on anything after the max size of $_POST is exceeded is almost pointless as the entire reference to the form build id is lost. The only solution that I have found so far is to change theme_form to append the action with the build id. This ensures that this is never lost and a failed POST can be detected.

The attached patch simply tags the form with the form build id so that it is always passed back to the server on form submission.

<?php
// Original
function theme_form($element) {
  // Anonymous div to satisfy XHTML compliance.
  $action = $element['#action'] ? 'action="' . check_url($element['#action']) . '" ' : '';
  return '<form ' . $action . ' accept-charset="UTF-8" method="' . $element['#method'] . '" id="' . $element['#id'] . '"' . drupal_attributes($element['#attributes']) . ">\n<div>" . $element['#children'] . "\n</div></form>\n";
}

// Modified
function theme_form($element) {
  // PHP drops the $_POST array if this exceeds the PHP setting post_max_size.
  $action = '';
  if ($element['#action']) {
    $action = 'action="' . check_url($element['#action']) . (strpos($element['#action'], '?') !== FALSE ? '&' : '?') . 'form-id=' . check_plain($element['#build_id']) . '"';
  }
  // Anonymous div to satisfy XHTML compliance.
  return '<form ' . $action . ' accept-charset="UTF-8" method="' . $element['#method'] . '" id="' . $element['#id'] . '"' . drupal_attributes($element['#attributes']) . ">\n<div>" . $element['#children'] . "\n</div></form>\n";
}

?>

So with the modifications, a var_dump on $_GET and $_POST normally will result in something like:

<?php
var_dump($_GET);
/*
Outputs
array(2) {
  ["q"]=>
  string(31) "admin/settings/site-information"
  ["form-id"]=>
  string(37) "form-f3b2569b7299435726c96c962dab3d89"
}
*/
var_dump($_POST);
/*
array(11) {
  ["site_name"]=>
  string(5) "d7dev"
  ["site_mail"]=>
....
}
*/
?>

But if max_post_size is exceeded:

<?php
var_dump($_GET);
/*
Outputs
array(2) {
  ["q"]=>
  string(31) "admin/settings/site-information"
  ["form-id"]=>
  string(37) "form-f3b2569b7299435726c96c962dab3d89"
}
*/
var_dump($_POST);
/*
array(0) {
}
*/
?>

In both cases, we can still retain the actual form that was originally posted and also detect if the form data has been dropped.

I'll leave it to someone with extensive FAPI experience to decide on the best approach if this primarily step in form validation is added to core.

Eg: Try to detect during form build: If empty($_POST) && valid($_GET[form_build_id]), tag as invalid submission.

Files: 
CommentFileSizeAuthor
form.build-id.1.patch1.06 KBAlan D.
Failed: Failed to install HEAD. View

Comments

drewish’s picture

Status: Active » Needs review

subscribing. wanted to mention that this is a follow up to #30520-19: file_save_upload() not notifying user when PHP upload limit is exceeded. where gabor pointed to this as a solution. i'd advocated deferring that part of the issue, well it's time to start on that portion.

Status: Needs review » Needs work

The last submitted patch failed testing.

danielb’s picture

subscribed
Not happy that this error handling is being attempted by particular module developers, and not consistently applied by FAPI.
also upload_max_filesize in file fields

Alan D.’s picture

Version: 7.x-dev » 8.x-dev

This is too late for D7 now as this would be considered an API change.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.