Загадково порожній масив $ _POST


21

У мене є така 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&"

Так чи інакше, масив з ім'ям тесту випорожнюється, змінна "action" робить це до кінця.

Я використовував розширення заголовків HTTP Live для Firefox, щоб перевірити, чи надсилаються поля POST, і чи є вони. Відповідна інформація з Live HTTP заголовків (із символами 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 - поточний. Схоже, тут проблем немає, правда?


4
Сухосін може бути.
Полковник Шрапнель

Так, сухосін звучить як вірогідний кандидат
SeanJA

Не могли б ви дати трохи більше інформації? Suhosin встановлений на сервері, чи слід його вимкнути? Чи варто змінити налаштування?
rael_kid

3
Спробуйте це, він увійде, якщо це проблема сихосину. hardened-php.net/suhosin/configuration.html#suhosin.simulation

Я спробував увімкнути режим моделювання. Масив все ще спорожняється. Я, здається, не можу знайти файли журналів ...
rael_kid

Відповіді:


2

Чи працює це без явних індексів? Спробуйте:

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

Ні, теж не працює.
rael_kid

Не встановлюйте індекси для тестового масиву - вони зіпсують виявлення змінної POST
adam

2
Гаразд, я можу їх залишити. Але це не вирішує мою проблему.
rael_kid

2

Існує ряд можливих причин, чому масив публікацій може бути порожнім - ймовірність того, що він повернеться до помилки людини / розробника. Цю проблему я відчув під час оновлення з 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 :)


1

Звіти про помилки щодо цієї чи подібних проблем у програмі виправлення помилок PHP:

На жаль, це рішення не згадується, але ви можете спробувати встановити інший тип CONTENT_TYPE або взагалі відсутній тип вмісту.


Ці помилки схожі, але не такі, як у мене. Я намагався встановити тип вмісту (як ви бачите в фрагменті коду в моїй оригінальній відповіді). Якщо я взагалі не встановив тип вмісту, він також не працює ...
rael_kid

1

Була досить схожа проблема. Ну, по-перше, мені знадобилося досить багато часу, щоб дістатися до цієї посади. Щоб з'ясувати назву моєї проблеми, мені довелося встановити консоль 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'

І вуаля, магія і веселки, і єдинороги, і мій сайт нарешті працює!

PS Метерення з налаштуваннями хостингу також може вирішити вашу проблему ... Якщо ваша проблема схожа на мою, звичайно ...


Блін. Перенаправлення теж було моєю проблемою!
Аман Алам

0

Я не впевнений, але маю

name="test[1]"

тощо може збити з пантелику php. Я б змінив імена входів на test_1, test_2 і побачив, що відбувається.


7
@haavee: Ні, PHP рекламує це використання: php.net/manual/en/faq.html.php#faq.html.arrays
Boldewyn

Я спробував це, таким чином змінні працюють, але вони не в масиві.
rael_kid

@haavee: Ні, позначення не плутає PHP, це стандартне використання PHP + форм. Дивіться посилання Болдевіна. :)

добре, THX! сьогодні дізналися щось нове.

1
@adam: "Також можна призначити конкретні ключі для ваших масивів".

0

У базовій 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, видалення їх каталогів, очищення пакетів, перевстановлення та початок повернення фрагментів конфігурації на місце, поки код не перестане працювати знову (по черзі, почати оновлення цього сервера це працює з конфігураціями з нефункціонуючого сервера, поки вони обидва не зламані). Оскільки у вас сервер з тією ж ОС-PHP працює коректно, це майже напевно помилка конфігурації на несправному сервері десь, але це досить великий стог сіна для пошуку.

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


Мій post_max_size 8М, я думаю, цього було б достатньо. Мої php.ini не містять записів із сухосіном у ньому, тому це може бути проблемою ... Чи є у suhosin власні конф-файли?
rael_kid

Не за замовчуванням, але параметри для будь-якого модуля PHP можна встановити будь-яким файлом в /etc/php5/conf.d в системі Debian, і тому я вважаю також систему Ubuntu. Як я вже казав, це було щось тривале. Все-таки я б почав з того, щоб відрізняти кожен конфігураційний файл від робочої системи.
Зед

0

У мене виникають збої в надсиланні форми з моменту переходу на "тестування" Debian з "стабільного". Видається, що apache2 або php5 не обробляє декілька елементів у програмі з тим самим іменем. Наприклад; у вашій формі є два входи, назва "мо". У минулому лише одне із значень для "mo" пробило б це. Тепер форма, здається, скидає всі дані після першого появи дублюючого ключа. Ще не впевнений. Ще намагаюся розібратися в цьому.


0

Спробуйте скопіювати php.ini з того сервера, який працює на цьому (хоча б спочатку створити резервну копію php.ini непрацюючого сервера). Якщо це так, то щось там є (можливо, змінна_порядок або, можливо, пам'ять, однак навряд чи обидва).


0

Спробуйте перейменувати кнопку подання на щось інше, ніж на дію. У мене були проблеми з цим у минулому. Мабуть, вхід із назвою "дія" є проблемою.


0

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

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

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

Але вам слід остаточно спробувати і змінити порядок змінних.


0

Навіть ця ОП досить стара, але сьогодні я зіткнувся з подібною проблемою.

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

А після встановлення вибраного - все повернеться до нормального :-)

введіть тут опис зображення

Сподіваюся, це допоможе будь-яким майбутнім читачам


0

Якщо це може допомогти комусь іншому ... Я просто витратив години, щоб вирішити подібну проблему, і проблема полягала в обмеженні php.ini max_input_vars = "1000". Не забудьте перевірити значення php.ini завантаження_max_filesize, post_max_size та max_input_vars. Якщо перевищити один, ви отримаєте порожній масив $ _POST.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.