I just helped a friend get through a devious issue with his PHP installation that I thought i’d blog about. There are other posts discussing problems related to having a $_POST array be completely empty although reading POST data directly via php://input wrappers works.
I used a similar test file to try and determine what was happening in the first place:
<?php
print "CONTENT_TYPE: " . $_SERVER['CONTENT_TYPE'] . "<BR />";
$data = file_get_contents('php://input');
print "DATA: <pre>";
var_dump($data);
var_dump($_POST);
print "</pre>";
?>
<form method="post">
<input type="text" name="name" value="ok" />
<input type="submit" name="submit" value="submit" />
</form>
If you submit the form and you see this as the result:
CONTENT_TYPE: application/x-www-form-urlencoded
DATA:
string(21) "name=ok&submit=submit"
array(0) {
}
… then that means that your browser is correctly submitting the right CONTENT_TYPE, and is also sending the browser POST data correctly. PHP is also seeing the right raw post data via the raw POST input wrapper, but the $_POST superglobal is totally empty.
What this eventually got tracked down to was an update in the php.ini that changed post_max_size from “8M” to “10MB”. Did you catch that? The use of “MB” instead of “M” was invalid, but instead of throwing an error on startup, PHP internally interpreted this as a “0″ since it was invalid. Since the post_max_size was effectively zero, nothing made it into the $_POST array.
Hope this helps anyone else debugging a similar issue! Oh, and hopefully it goes without saying, make sure you delete this test file as soon as you’re done, but it’s a giant XSS hole waiting to happen.