Issue crosses between caching, forms, AJAX, and file.

Issue appears in 7.50 when an anonymous user comes to a form (noticed in webform and enitityform, though I suppose you could have an anonymous accessible /node/add or comment form) with multiple AJAX file uploaders. System has page caching on. The anonymous user uploads to one File field successfully. She tries to upload a file in the second File field. Returns "An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (2 MB) that this server supports."

Reproduction: stock 7.50. Enable webform and its dependencies. Create a webform with two File upload fields. Enable basic page caching. Log out and access form as anonymous. Attempt to upload files in both File fields. (browser must have JS enabled). Second upload will give the "An unrecoverable error occurred" dialog.

The problem: because the form was anonymous/cached, the DOM-inserting (fid_token) code in 6b6bc1b7 ends up updating the form_build_id value on the containing form via the AJAX callback. (Search for 'immutable' in form.inc). Okay. However, the submission of the other AJAX form (the other File field) still gets sent to the AJAX POST endpoint of the old and bad form_build_id. Basically, the AJAX update of the form_build_id doesn't modify the target POST addresses in other AJAX forms, and they aren't generating their POST locations on the fly.

D8: While 2678822 had a similar fix in D8.1.1, the POST endpoints are not based on form_build_id, so it doesn't appear to be a problem.

Quick workaround: cacheexclude pages that are affected (i.e., the entityform in our case).

Still thinking a bit on a more proper solution.

CommentFileSizeAuthor
#6 drupal-2787243-updateBuildId-for-ajax-file-uploads-6.patch831 bytestorotil
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tshorock created an issue. See original summary.

tshorock’s picture

tshorock CreditAttribution: tshorock commented
Issue summary: View changes
tshorock’s picture

tshorock CreditAttribution: tshorock commented
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)
tshorock’s picture

tshorock CreditAttribution: tshorock commented

The problem is real, but it didn't just show up in 7.50 with the commit I thought I was blaming. Failed on 7.44 testing, will test in older D7s.

tshorock’s picture

tshorock CreditAttribution: tshorock commented

Just in case anyone finds this issue by searching for this error, I've found that it goes back to the 7.27 security patch in April 2014. 7.26 doesn't reproduce the problem above, 7.27 (and through to 7.50) does. Not a file.module problem specifically.

Again, the workaround of using cacheexclude on the form works.

torotil’s picture

torotil CreditAttribution: torotil at more onion commented
Version: 7.5 » 7.x-dev
Status: Postponed (maintainer needs more info) » Needs review
FileSize
drupal-2787243-updateBuildId-for-ajax-file-uploads-6.patch831 bytes

Here is an attempt to work around this problem by updating all the Drupal.ajax objects and their settings according to the new form build id. For me this makes multiple file-uploads work on a cached page again.

poker10’s picture

poker10 CreditAttribution: poker10 at ActivIT s.r.o. commented
Status: Needs review » Closed (duplicate)
Related issues: +#2392117: Forms with multiple file form elements produce upload errors with the Drupal page cache enabled

I think this is a duplicate of: #2392117: Forms with multiple file form elements produce upload errors with the Drupal page cache enabled. This issue is newer, so closing it. However, the approach here seems to be more reasonable than the attempts to remove the check altogether in the referenced issue.