Home > Tech > PHP $_POST array empty although php://input and raw post data is available?

PHP $_POST array empty although php://input and raw post data is available?

February 24th, 2009

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.

Tech

  1. Norse
    March 3rd, 2009 at 06:09 | #1

    You sir are a gentleman and a scholar.

    This was exactly the problem I was having. I modified my php.ini months ago and must have never noticed that POST didn’t work after that, it was only today when I went to write a quick script that relied on POST data and found that it wasn’t working.

    Thank you!

  2. Jack
    March 10th, 2009 at 06:27 | #2

    Woo who! Thanks for the heads up. I would have spent forever on this.

  3. March 10th, 2009 at 12:21 | #3

    Glad I could help!

  4. April 13th, 2009 at 10:31 | #4

    I was running into a blank POST array today, but turns out that the reason mine was empty was that my postmaxsize variable in php.ini was set to higher than the amount of physical RAM in the machine.

    Thanks for the script, It helped me debug the issue.

  5. Tobias
    July 24th, 2009 at 11:05 | #5

    Great! Same problem as Mark… Thanks. You saved my day.

  6. September 2nd, 2009 at 22:59 | #6

    I just had the same, problem but opposite cause. Under PHP 5.3.0 I had to change from “200MB” to “200M” and it worked. Ridiculous. Thanks for the tip, though, it put the idea in my head to try it!

  7. September 3rd, 2009 at 15:35 | #7

    Actually, this is the same cause – if you read the post carefully, “MB” is invalid, but “M” is correct. It’s tricky!

  8. October 27th, 2009 at 11:16 | #8

    Here’s another possible cause — my form was submitting to http://domain.com/ and I had set up an automatic redirect to add the “WWW.” The $_POST array was getting emptied in the process. So to fix it all I had to do was submit to http://www.domain.com/

  9. December 4th, 2009 at 17:29 | #9

    Cesar: good point. This is the type of thing that Firebug is really handy for – if you can see via the Net panel that it’s following a 302 redirect instead of sending a POST payload, you should be able to figure out what’s going on pretty quickly.

  10. branio
    February 19th, 2010 at 08:18 | #10

    Cesar: Thanks! It solved my problem! I’m happy now :)

  1. No trackbacks yet.