recaptime.dev / phorge
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

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

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.

Maniphest Tasks: T4369

Differential Revision: https://secure.phabricator.com/D21165

epriestley 6f714737 5a460e4e

+6 -11
+6 -11
src/aphront/configuration/AphrontApplicationConfiguration.php
··· 812 812 // if we can. Among other things, this corrects variable names with 813 813 // the "." character in them, which PHP normally converts into "_". 814 814 815 - // There are two major considerations here: whether the 816 - // `enable_post_data_reading` option is set, and whether the content 817 - // type is "multipart/form-data" or not. 818 - 819 - // If `enable_post_data_reading` is off, we're free to read the entire 820 - // raw request body and parse it -- and we must, because $_POST and 821 - // $_FILES are not built for us. If `enable_post_data_reading` is on, 822 - // which is the default, we may not be able to read the body (the 823 - // documentation says we can't, but empirically we can at least some 824 - // of the time). 815 + // If "enable_post_data_reading" is on, the documentation suggests we 816 + // can not read the body. In practice, we seem to be able to. This may 817 + // need to be resolved at some point, likely by instructing installs 818 + // to disable this option. 825 819 826 820 // If the content type is "multipart/form-data", we need to build both 827 821 // $_POST and $_FILES, which is involved. The body itself is also more 828 822 // difficult to parse than other requests. 823 + 829 824 $raw_input = PhabricatorStartup::getRawInput(); 830 825 $parser = new PhutilQueryStringParser(); 831 826 832 827 if (strlen($raw_input)) { 833 828 $content_type = idx($_SERVER, 'CONTENT_TYPE'); 834 829 $is_multipart = preg_match('@^multipart/form-data@i', $content_type); 835 - if ($is_multipart && !ini_get('enable_post_data_reading')) { 830 + if ($is_multipart) { 836 831 $multipart_parser = id(new AphrontMultipartParser()) 837 832 ->setContentType($content_type); 838 833