Mysteriously empty $_POST array

Question

I have the following HTML/PHP page:

<?php
if(empty($_SERVER['CONTENT_TYPE'])) {
    $type = "application/x-www-form-urlencoded";
    $_SERVER['CONTENT_TYPE'] = $type;
}

echo "<pre>";
var_dump($_POST);
var_dump(file_get_contents("php://input"));
echo "</pre>";
?>

<form method="post" action="test.php">
<input type="text" name="test[1]" />
<input type="text" name="test[2]" />
<input type="text" name="test[3]" />
<input type="submit" name="action" value="Go" />
</form>

As you can see, the form will submit and the expected output is a POST array with one array in it containing the filled in values and one entry "action" with the value "Go" (the button). However, no matter what values I enter in the fields; the result is always:

array(2) {
  ["test"]=>
  string(0) ""
  ["action"]=>
  string(2) "Go"
}
string(16) "test=&action=Go&"

Somehow, the array named test is emptied, the "action" variable does make it through.

I've used the Live HTTP Headers extension for Firefox to check whether the POST fields get submitted, and they do. The relevant information from Live HTTP Headers (with a, b and c filled in as values in the textboxes):

Content-Type: application/x-www-form-urlencoded
Content-Length: 51
test%5B1%5D=a&test%5B2%5D=b&test%5B3%5D=c&action=Go

Does anybody have any idea as to why this is happening? I'm freaking out on this one, it has cost me so much time already...

Update:

We've tried this on different servers, on Windows boxes it does work, on the Ubuntu server with PHP version 5.2.4 (with Suhosin), it doesn't. It even works on a different server, also with Ubuntu and the same PHP version, also with Suhosin installed.

I've diffed the two files, this is the output (diff php.ini phps.ini):

270c270
< memory_limit = 32M
---
> memory_limit = 16M      ; Maximum amount of memory a script may consume (16MB)
415c415
< variables_order = "EGCSP"
---
> variables_order = "EGPCS"
491d490
< include_path = ".:"
1253a1253,1254
> extension=mcrypt.so
>

In this phps.ini is the one from the server on which it works and php.ini is the current one. Looks as if there are no problems here, right?

Answer 1

There's a number of possible reasons why the post array could be empty - chances have that it comes back to human/developer error. I experienced this exact issue when upgrading from PHP 5.2 to 5.4, it was simple but it took hours of troubleshooting to find the bug. In our config.php file we had the below statement to process $_POST arrays:

if (!get_magic_quotes_gpc()) {
    if (isset($_POST)) {
        foreach ($_POST as $key => $value) {
            $_POST[$key] =  trim(addslashes($value));
        }
    }

Magic quotes was once on, and in PHP versions up to 5.2 the above worked fine but anything above version 5.2 it won't process and an empty array is returned.

If you don't have error_reporting() switched on I suggest that you do and I'm sure you'll be able to troubleshoot the issue.

You should also check for deprecated system features, like "magic_quotes" as using them simply fails to return results. I hope this helps. Best of luck. JCS :)

Answer 2

Does it work without the explicit indices? Try:

<form method="post" action="test.php">
<input type="text" name="test[]" />
<input type="text" name="test[]" />
<input type="text" name="test[]" />
<input type="submit" name="action" value="Go" />
</form>

Answer 3

There are bug reports on this or similar issues in PHP's bugtracker:

• http://bugs.php.net/bug.php?id=49945
• http://bugs.php.net/bug.php?id=45043

Unfortunately it doesn't mention a solution, but you could try to set another CONTENT_TYPE or no content type at all.

Answer 4

Had a quite similar problem. Well, first of all it took me quite a while to get to this post. To figure out the name of my problem, I had to install PHP console, figure out how to use it. Debug the code that I knew nothing about. Get to the root of the problem and still be puzzled.

The solution was pretty simple actually. In Chrome, press F12 to get to developer tools, select Network, try posting your form. Trace post request, look at the status. If its 301 (or anything else other than 200) - you are having same exact problem that I was having until recently!

My new host provider was redirecting http://my_site.com to http://www.my_site.com, all I had to do is change some settings as part of my CMS (yours might be different but similar in a way) from

$Configuration['BASE_URL'] = 'http://my_site.com'

to

$Configuration['BASE_URL'] = 'http://www.my_site.com'

And voila, the magic and the rainbows and the unicorns and my site is finally working!

P.S. Messing with your hosting settings might also solve your problem... If your problem is similar to mine of course...

Answer 5

I'm not sure but having

name="test[1]"

etc. may confuse php. I'd change the input names to test_1, test_2 and see what happens.

Answer 6

In base PHP, I can think of only one configuration option that could break this, which is post_max_size, so check your php.ini and related files to make sure that this value is sane and not set to zero or an invalid value like an alphabetic character.

Suhosin makes it possible to block post variables on a variety of conditions, including such things as array length and variable name length. Grep your php.ini files for 'suhosin' to see if any settings are present, particularly anything starting with 'suhosin.post'. (See http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.max_array_depth for more details on the parameters I'm thinking of.)

Unfortunately, barring a major screwup in configuration that set some value to one or zero, your code (and variables) are short enough that this is something of a long shot. If that comes up blank, my next suggestion would be to backup your Apache and PHP configs, nuke their directories, purge the packages, reinstall, and start putting config chunks back into place until the code stops working again (alternately, start updating that server that's working with configs from the nonfunctioning server until they're both broken). Since you have same-OS-same-PHP server working correctly, this is almost certainly a configuration error on the malfunctioning server somewhere, but that's a pretty large haystack to search through.

Version control of /etc is highly recommended before you start this -- look into the etckeeper package. (Actually, I recommend its use, period. Major sanity saver, particularly on a machine where more than one person has root access.)

Answer 7

I am having form submittion failures all over the place since I upgraded to Debian "testing" from "stable". It appears that apache2 or php5 is not handling multiple items in the submission with the same name. For example; your form has two inputs name "mo". In the past only one of the values for "mo" would make it through. Now the form seems to drop all data after the first occurence of a duplicate key. Not sure yet. Still trying to figure it out.

Answer 8

Try copying over the php.ini from the server that works to this one (backup the non-working server's php.ini first though). If it does, it's something in there (perhaps the variables_order, or possibly memory, both unlikely though).

Answer 9

Try renaming your submit button to something other than action. I've had some problems with this in the past. Having an input named 'action' seems to be the problem.

Answer 10

The following should NOT help you. It stands against everything I know of the PHP Configuration:

< variables_order = "EGCSP"
---
> variables_order = "EGPCS"

This one jumped on me. Your superglobals are getting registered in different orders. This just shouldn't be a problem because since you aren't using register_globals and don't rely on them it shouldn't be a problem to change the order in which order variables are being processed.

But you should definitively give it a try and change the order of the variables.

Answer 11

Even that OP is pretty old, but today I encountered a similar problem.

After spending a few hours checking million different stuff over and over, eventually found out that after last update to PHP 5.6.17 version in our cPanel at PHP defaults settings the http wasn't selected.

And after setting it to selected - everything back to normal :-)

Hope it will help any future readers

Answer 12

If this can help anyone else... I just spent hours to fix a similar issue and the problem was the max_input_vars = "1000" limit of php.ini. Be sure to check php.ini values of upload_max_filesize, post_max_size and max_input_vars. Exceeding one will results with an empty $_POST array.

Answer 13

not sure if this is already answered after 3 years. I am seeing this error today. after some comparison with a working server, I make this changes and it work.

magic_quotes_gpc = On (from off - not working) in the php.ini

my php version 5.3.3 OS Centos 6.10