Назад | Перейти на главную страницу

Загадочно пустой массив $ _POST

У меня есть следующая страница HTML / PHP:

<?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>

Как вы можете видеть, форма будет отправлена, и ожидаемым результатом будет массив POST с одним массивом в нем, содержащим заполненные значения, и одной записью «действие» со значением «Перейти» (кнопка). Однако независимо от того, какие значения я ввожу в поля; результат всегда:

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

Каким-то образом массив с именем test опустошается, а переменная "действие" проходит.

Я использовал расширение Live HTTP Headers для Firefox, чтобы проверить, отправляются ли поля POST, и они это сделали. Соответствующая информация из Live HTTP Headers (с заполненными значениями a, b и c в текстовых полях):

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

Кто-нибудь знает, почему это происходит? Меня это бесит, это уже стоило мне столько времени ...

Обновить:

Мы пробовали это на разных серверах, на ящиках Windows это работает, на сервере Ubuntu с PHP версии 5.2.4 (с Suhosin) нет. Он даже работает на другом сервере, также с Ubuntu и той же версией PHP, также с установленным Suhosin.

Я сравнил два файла, это результат (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
>

Здесь phps.ini - это файл с сервера, на котором он работает, а php.ini - текущий. Похоже, здесь нет никаких проблем?

Это работает без явные индексы? Пытаться:

<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>

Существует ряд возможных причин, по которым массив сообщений может быть пустым - есть вероятность, что это связано с ошибкой человека / разработчика. У меня возникла именно эта проблема при обновлении с PHP 5.2 до 5.4, это было просто, но потребовались часы устранения неполадок, чтобы найти ошибку. В нашем файле config.php у нас есть следующий оператор для обработки массивов $ _POST:

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

Волшебные кавычки когда-то были включены, и в версиях PHP до 5.2 вышеуказанное работало нормально, но все, что выше версии 5.2, не обрабатывается, и возвращается пустой массив.

Если у вас нет error_reporting() включен Я предлагаю вам это сделать, и я уверен, что вы сможете устранить проблему.

Вам также следует проверить устаревшие системные функции, такие как "magic_quotes"поскольку их использование просто не дает результатов. Надеюсь, это поможет. Удачи. JCS :)

В багтрекере PHP есть отчеты об этой или подобных проблемах:

К сожалению, в нем не упоминается решение, но вы можете попробовать установить другой CONTENT_TYPE или вообще не использовать тип содержимого.

Была похожая проблема. Ну, во-первых, мне потребовалось довольно много времени, чтобы добраться до этого поста. Чтобы выяснить название моей проблемы, мне пришлось установить консоль PHP, разобраться, как ее использовать. Отлаживайте код, о котором я ничего не знал. Доберитесь до корня проблемы и все равно будете озадачены.

На самом деле решение было довольно простым. В Chrome нажмите F12, чтобы перейти к инструментам разработчика, выберите Сеть и попробуйте опубликовать форму. Проследите почтовый запрос, посмотрите статус. Если это 301 (или что-то еще, кроме 200) - у вас точно такая же проблема, как и у меня до недавнего времени!

Мой новый хост-провайдер перенаправлял http://my_site.com к http://www.my_site.com, все, что мне нужно было сделать, это изменить некоторые настройки как часть моей CMS (ваша может быть другой, но в чем-то похожей) из 

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

к

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

И вуаля, магия, радуга, единороги и мой сайт наконец-то заработали!

P.S. Возникновение с настройками хостинга также может решить вашу проблему ... Если ваша проблема, конечно, похожа на мою ...

Я не уверен, но имея 

name="test[1]"

и т.д. может запутать php. Я бы изменил имена входов на test_1, test_2 и посмотрел, что произойдет.

В базовом PHP я могу придумать только один вариант конфигурации, который может нарушить это, а именно post_max_size, поэтому проверьте свой php.ini и связанные файлы, чтобы убедиться, что это значение разумно и не установлено на ноль или недопустимое значение, например буквенный символ.

Suhosin позволяет блокировать пост-переменные при различных условиях, включая такие вещи, как длина массива и длина имени переменной. Найдите в своих файлах php.ini «suhosin», чтобы увидеть, присутствуют ли какие-либо настройки, особенно все, что начинается с «suhosin.post». (Видеть http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.max_array_depth подробнее о параметрах, о которых я думаю.)

К сожалению, если не допустить серьезной ошибки в конфигурации, которая устанавливает какое-то значение на единицу или ноль, ваш код (и переменные) достаточно короткие, так что это далеко не единственный шанс. Если это окажется пустым, моим следующим предложением будет сделать резервную копию ваших конфигураций Apache и PHP, уничтожить их каталоги, очистить пакеты, переустановить и начать возвращать блоки конфигурации на место, пока код снова не перестанет работать (в качестве альтернативы, начните обновление этого сервера. который работает с конфигами с нефункционирующего сервера, пока они оба не сломаются). Поскольку у вас есть сервер same-OS-same-PHP, работающий правильно, это почти наверняка ошибка конфигурации где-то на неисправном сервере, но это довольно большой стог сена для поиска.

Перед тем, как начать, настоятельно рекомендуется контролировать версии / etc - загляните в пакет etckeeper. (На самом деле, я рекомендую его использовать, точка. Основная экономия на рассудке, особенно на машине, где более одного человека имеют root-доступ.)

У меня повсюду возникают сбои при отправке формы с тех пор, как я перешел на Debian "тестирование" со "стабильного". Похоже, что apache2 или php5 не обрабатывают несколько элементов в отправке с одинаковым именем. Например; ваша форма имеет два входа с именем «mo». Раньше выдерживалось только одно из значений «mo». Теперь форма, кажется, удаляет все данные после первого появления повторяющегося ключа. Пока не уверен. Все еще пытаюсь понять это.

Попробуйте скопировать php.ini с работающего сервера на этот (хотя сначала сделайте резервную копию php.ini неработающего сервера). Если это так, то это что-то там (возможно, переменные_order или, возможно, память, хотя и то, и другое маловероятно).

Попробуйте переименовать кнопку отправки не в действие. У меня были проблемы с этим в прошлом. Кажется, проблема заключается в наличии ввода с именем «действие».

Следующее НЕ должно вам помочь. Это противоречит всему, что я знаю о конфигурации PHP:

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

Этот набросился на меня. Ваши суперглобалы регистрируются в разном порядке. Это не должно быть проблемой, потому что, поскольку вы не используете register_globals и не полагайтесь на них, не должно быть проблем изменить порядок, в котором обрабатываются переменные порядка.

Но вы должны окончательно попробовать и изменить порядок переменных.

Даже этот OP довольно старый, но сегодня я столкнулся с аналогичной проблемой.

Проведя несколько часов, проверяя миллионы разных вещей снова и снова, в конце концов выяснилось, что после последнего обновления PHP 5.6.17 версия в нашей cPanel в настройках PHP по умолчанию http не был выбран.

А после установки на selected - все возвращается в норму :-)

Надеюсь, это поможет любым будущим читателям

Если это может помочь кому-то еще ... Я просто потратил часы, чтобы исправить аналогичную проблему, и проблема заключалась в ограничении max_input_vars = "1000" для php.ini. Не забудьте проверить в php.ini значения upload_max_filesize, post_max_size и max_input_vars. Превышение единицы приведет к пустому массиву $ _POST.