Page MenuHomePhabricator

Parse "multipart/form-data" bodies even if "enable_post_data_reading" is on
ClosedPublic

Authored by epriestley on Apr 24 2020, 6:10 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Jan 28, 1:10 PM
Unknown Object (File)
Sat, Jan 25, 7:20 AM
Unknown Object (File)
Sat, Jan 25, 7:19 AM
Unknown Object (File)
Sat, Jan 25, 7:19 AM
Unknown Object (File)
Fri, Jan 24, 5:22 AM
Unknown Object (File)
Thu, Jan 23, 3:58 PM
Unknown Object (File)
Tue, Jan 21, 11:39 PM
Unknown Object (File)
Tue, Jan 21, 12:58 PM
Subscribers
None

Details

Summary

Ref T4369. During T13507, I set my "max_post_size" to a very small value, like 7 (i.e., 7 bytes). This essentially disables "enable_post_data_reading" even if the setting is technically on.

This breaks forms which use "multipart/form-data", which are rare but not nonexistent. Notably, forms in Config use this setting (because of ui.header stuff?) although perhaps they should not or no longer need to.

This can be fixed by parsing the raw input.

Since the only reason we don't parse the raw input is concern that we may not be able to read it (per documentation, but never actually observed), and we do a strlen() test anyway, just read it unconditionally.

This should fix cases where POST data wasn't read because of "max_post_size" without impacting anything else.

Test Plan

With very small "max_post_size", updated "ui.footer-items" in Config. Before: form acted as a no-op. After: form submitted.

Diff Detail

Repository
rP Phabricator
Branch
foot1
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 24211
Build 33347: Run Core Tests
Build 33346: arc lint + arc unit