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)
Sun, Mar 31, 11:32 AM
Unknown Object (File)
Sat, Mar 30, 4:02 AM
Unknown Object (File)
Fri, Mar 29, 3:49 PM
Unknown Object (File)
Mar 4 2024, 6:53 PM
Unknown Object (File)
Feb 13 2024, 8:05 PM
Unknown Object (File)
Feb 4 2024, 12:07 AM
Unknown Object (File)
Feb 2 2024, 4:03 AM
Unknown Object (File)
Dec 26 2023, 6:11 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
Lint
Lint Not Applicable
Unit
Tests Not Applicable