diff --git a/src/aphront/configuration/AphrontApplicationConfiguration.php b/src/aphront/configuration/AphrontApplicationConfiguration.php
index c0e66f3251..5bed835d8f 100644
--- a/src/aphront/configuration/AphrontApplicationConfiguration.php
+++ b/src/aphront/configuration/AphrontApplicationConfiguration.php
@@ -812,27 +812,22 @@ final class AphrontApplicationConfiguration
     // if we can. Among other things, this corrects variable names with
     // the "." character in them, which PHP normally converts into "_".
 
-    // There are two major considerations here: whether the
-    // `enable_post_data_reading` option is set, and whether the content
-    // type is "multipart/form-data" or not.
-
-    // If `enable_post_data_reading` is off, we're free to read the entire
-    // raw request body and parse it -- and we must, because $_POST and
-    // $_FILES are not built for us. If `enable_post_data_reading` is on,
-    // which is the default, we may not be able to read the body (the
-    // documentation says we can't, but empirically we can at least some
-    // of the time).
+    // If "enable_post_data_reading" is on, the documentation suggests we
+    // can not read the body. In practice, we seem to be able to. This may
+    // need to be resolved at some point, likely by instructing installs
+    // to disable this option.
 
     // If the content type is "multipart/form-data", we need to build both
     // $_POST and $_FILES, which is involved. The body itself is also more
     // difficult to parse than other requests.
+
     $raw_input = PhabricatorStartup::getRawInput();
     $parser = new PhutilQueryStringParser();
 
     if (strlen($raw_input)) {
       $content_type = idx($_SERVER, 'CONTENT_TYPE');
       $is_multipart = preg_match('@^multipart/form-data@i', $content_type);
-      if ($is_multipart && !ini_get('enable_post_data_reading')) {
+      if ($is_multipart) {
         $multipart_parser = id(new AphrontMultipartParser())
           ->setContentType($content_type);