@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
Remove the (hopefully) obsolete "post_max_size" check during startup
Summary:
Ref T13507. See that task for discussion. This check appears to be obsolete in all common cases and misfires if the client submits compressed requests.
Since the cases where it could still trigger correctly are extremely rare and should still have plausible behavior, just remove it.
Test Plan: Grepped for calls.
Maniphest Tasks: T13507
Differential Revision: https://secure.phabricator.com/D21077
-100
-100
support/startup/PhabricatorStartup.php
-100
support/startup/PhabricatorStartup.php
···
142
142
143
143
self::verifyRewriteRules();
144
144
145
-
self::detectPostMaxSizeTriggered();
146
-
147
145
self::beginOutputCapture();
148
146
}
149
147
···
580
578
"are not configured correctly. The '__path__' should always ".
581
579
"begin with a '/'.");
582
580
}
583
-
}
584
-
585
-
586
-
/**
587
-
* Detect if this request has had its POST data stripped by exceeding the
588
-
* 'post_max_size' PHP configuration limit.
589
-
*
590
-
* PHP has a setting called 'post_max_size'. If a POST request arrives with
591
-
* a body larger than the limit, PHP doesn't generate $_POST but processes
592
-
* the request anyway, and provides no formal way to detect that this
593
-
* happened.
594
-
*
595
-
* We can still read the entire body out of `php://input`. However according
596
-
* to the documentation the stream isn't available for "multipart/form-data"
597
-
* (on nginx + php-fpm it appears that it is available, though, at least) so
598
-
* any attempt to generate $_POST would be fragile.
599
-
*
600
-
* @task validation
601
-
*/
602
-
private static function detectPostMaxSizeTriggered() {
603
-
// If this wasn't a POST, we're fine.
604
-
if ($_SERVER['REQUEST_METHOD'] != 'POST') {
605
-
return;
606
-
}
607
-
608
-
// If "enable_post_data_reading" is off, we won't have $_POST and this
609
-
// condition is effectively impossible.
610
-
if (!ini_get('enable_post_data_reading')) {
611
-
return;
612
-
}
613
-
614
-
// If there's POST data, clearly we're in good shape.
615
-
if ($_POST) {
616
-
return;
617
-
}
618
-
619
-
// For HTML5 drag-and-drop file uploads, Safari submits the data as
620
-
// "application/x-www-form-urlencoded". For most files this generates
621
-
// something in POST because most files decode to some nonempty (albeit
622
-
// meaningless) value. However, some files (particularly small images)
623
-
// don't decode to anything. If we know this is a drag-and-drop upload,
624
-
// we can skip this check.
625
-
if (isset($_REQUEST['__upload__'])) {
626
-
return;
627
-
}
628
-
629
-
// PHP generates $_POST only for two content types. This routing happens
630
-
// in `main/php_content_types.c` in PHP. Normally, all forms use one of
631
-
// these content types, but some requests may not -- for example, Firefox
632
-
// submits files sent over HTML5 XMLHTTPRequest APIs with the Content-Type
633
-
// of the file itself. If we don't have a recognized content type, we
634
-
// don't need $_POST.
635
-
//
636
-
// NOTE: We use strncmp() because the actual content type may be something
637
-
// like "multipart/form-data; boundary=...".
638
-
//
639
-
// NOTE: Chrome sometimes omits this header, see some discussion in T1762
640
-
// and http://code.google.com/p/chromium/issues/detail?id=6800
641
-
$content_type = isset($_SERVER['CONTENT_TYPE'])
642
-
? $_SERVER['CONTENT_TYPE']
643
-
: '';
644
-
645
-
$parsed_types = array(
646
-
'application/x-www-form-urlencoded',
647
-
'multipart/form-data',
648
-
);
649
-
650
-
$is_parsed_type = false;
651
-
foreach ($parsed_types as $parsed_type) {
652
-
if (strncmp($content_type, $parsed_type, strlen($parsed_type)) === 0) {
653
-
$is_parsed_type = true;
654
-
break;
655
-
}
656
-
}
657
-
658
-
if (!$is_parsed_type) {
659
-
return;
660
-
}
661
-
662
-
// Check for 'Content-Length'. If there's no data, we don't expect $_POST
663
-
// to exist.
664
-
$length = (int)$_SERVER['CONTENT_LENGTH'];
665
-
if (!$length) {
666
-
return;
667
-
}
668
-
669
-
// Time to fatal: we know this was a POST with data that should have been
670
-
// populated into $_POST, but it wasn't.
671
-
672
-
$config = ini_get('post_max_size');
673
-
self::didFatal(
674
-
"As received by the server, this request had a nonzero content length ".
675
-
"but no POST data.\n\n".
676
-
"Normally, this indicates that it exceeds the 'post_max_size' setting ".
677
-
"in the PHP configuration on the server. Increase the 'post_max_size' ".
678
-
"setting or reduce the size of the request.\n\n".
679
-
"Request size according to 'Content-Length' was '{$length}', ".
680
-
"'post_max_size' is set to '{$config}'.");
681
581
}
682
582
683
583