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)
Fri, Nov 22, 5:31 PM
Unknown Object (File)
Sun, Nov 17, 6:22 PM
Unknown Object (File)
Thu, Nov 14, 9:59 AM
Unknown Object (File)
Tue, Nov 12, 5:56 AM
Unknown Object (File)
Sun, Nov 10, 8:33 AM
Unknown Object (File)
Wed, Nov 6, 9:52 AM
Unknown Object (File)
Oct 20 2024, 5:25 PM
Unknown Object (File)
Oct 16 2024, 4:47 AM
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