Enabling handling of errors related to max_post_size.

Created on 26 June 2009, about 15 years ago
Updated 18 June 2023, about 1 year ago

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.

<!--break-->
<?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.

✨ Feature request
Status

Postponed: needs info

Version

9.5

Component
FormΒ  β†’

Last updated 1 minute ago

Created by

πŸ‡¦πŸ‡ΊAustralia Alan D.

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024