php $ _POST массив пуст после отправки формы

Я знаю, что этот вопрос касался POST через форму, но пришел сюда, чтобы найти ответы на аналогичную проблему при POSTing с типом контента JSON. Нашел ответ и хотел поделиться им, поскольку это стоило мне много времени.

При использовании типа содержимого JSON массив $ _POST не будет заполняться (только с использованием многочастных форм, которые, как я полагаю)

Вот что помогло исправить проблему:

 $rest_json = file_get_contents("php://input"); $_POST = json_decode($rest_json, true); 

надеюсь, это поможет кому-то!

Вот еще одна возможная причина – моя форма отправляла на домен.com без WWW. и я настроил автоматическое перенаправление для добавления «WWW». Массив $ _POST опорожнялся в процессе. Поэтому, чтобы исправить это, мне нужно было отправить на http://www.domain.com

У меня была аналогичная проблема. Оказалось, что это простое решение. В той форме, которую я имел

<form action = "directory" method = "post">

где directory – это имя … каталога. Мой массив POST был полностью пуст. Когда я посмотрел на url в своем браузере, он был показан с косой чертой в конце.

Добавление косой черты к концу моего действия сделало трюк –

<form action = "directory /" method = "post">

Мой массив $ _POST снова заполнился!

Убедитесь, что в php.ini:

• track_vars (он доступен только на очень старых версиях PHP) установлен в положение On
• variables_order содержит букву P
• Значение post_max_size равно разумному (например, 8 МБ)
• (при использовании сухосинового пластыря) suhosin.post.max_vars и suhosin.request.max_vars достаточно велики.

Полагаю, второе мое решение решит вашу проблему.

На данный момент у вас нет элегантного решения, но я хотел бы поделиться своими выводами для будущих ссылок на других, сталкивающихся с этой проблемой. Источником проблемы было 2 переопределения значений php в файле .htaccess. Я просто добавил эти 2 значения, чтобы увеличить ограничение размера файлов для загрузки файлов с 8 МБ по умолчанию на нечто большее. Я заметил, что просто наличие этих двух значений в файле htaccess вообще, будь то больше или меньше, чем значение по умолчанию, вызвало проблему ,

 php_value post_max_size xxMB php_value upload_max_filesize xxMB 

Я добавил дополнительные переменные, чтобы надеяться на повышение пределов для всех suhosin.post.xxx/suhosin.upload.xxx vars, но к сожалению, это не имело никакого эффекта.

Таким образом, я не могу объяснить «почему» здесь, но определил причину. Я чувствую, что это, в конечном счете, проблема suhosin / htaccess, но, к сожалению, я не смог разрешить, кроме как удалить вышеперечисленные значения 2 php выше.

Надеюсь, это поможет кому-то в будущем, поскольку я убил несколько часов, выясняя это. Спасибо всем, кто нашел время, чтобы помочь мне с этим (MrMage, Andrew)

Я мог бы решить проблему, используя enctype = «application / x-www-form-urlencoded», поскольку по умолчанию это «text / plain». Когда вы проверяете $ DATA, разделитель представляет собой пробел для «text / plain» и специальный символ для «urlencoded».

С уважением, Франк

Я обнаружил, что при отправке с HTTP на HTTPS, $_POST пуст. Это произошло при проверке формы, но потребовалось некоторое время, пока я не осознаю это.

Я столкнулся с подобной, но немного другой проблемой, и для понимания проблемы потребовалось 2 дня.

• В моем случае массив POST был пуст.

• Затем проверяется с помощью file_get_contents ('php: // input'); и это тоже было пусто.

Позже я обнаружил, что браузер не запрашивал подтверждение повторной отправки данных формы после обновления страницы после загрузки POST. Это была непосредственно обновляющая страница. Но когда я изменил URL-адрес формы на другой, он правильно прошел POST и попросил повторно отправить данные при попытке обновить страницу.

Затем я проверил, что не так с фактическим URL. Не было ошибки в URL-адресе, однако он указывал на папку без index.php в URL-адресе, и я проверял POST на index.php.

Здесь я сомневался в перенаправлении с / на /index.php, что приводит к потере данных POST и проверке URL с добавлением index.php к URL-адресу.

Это работало.

Написал его здесь, чтобы кто-то нашел его полезным.

Если вы отправляете файл index.php в каталог, например, /api/index.php, убедитесь, что в вашей форме вы указываете полный каталог файла, например

Эта

 <form method="post" action="/api/index.php"> </form> 

ИЛИ

 <form method="post" action="/api/"> </form> 

работает.

Но это не удается

 <form method="post" action="/api"> </form> 

 <form action="test.php" method="post"> ^^^^^^^^^^^^^ 

Хорошо, это было глупо, и я буду стесняться публично, но я выбил небольшой тестовый скрипт для чего-то на PHP, и когда мой массив $_POST был пуст, StackOverflow – первое, на что я смотрел, и я не нашел ответа Мне было нужно.

Я только написал

 <form action="test.php"> 

и забыл указать метод как POST !

Я уверен, что кто-то будет хихикать, но если это поможет кому-то другому, кто делает то же самое, тогда я не возражаю! Мы все делаем это время от времени!

ССЫЛКА: http://www.openjs.com/articles/ajax_xmlhttp_using_post.php

Метод POST

Мы собираемся внести некоторые изменения, поэтому метод POST будет использоваться при отправке запроса …

 var url = "get_data.php"; var params = "lorem=ipsum&name=binny"; http.open("POST", url, true); //Send the proper header information along with the request http.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); http.setRequestHeader("Content-length", params.length); http.setRequestHeader("Connection", "close"); http.onreadystatechange = function() {//Call a function when the state changes. if(http.readyState == 4 && http.status == 200) { alert(http.responseText); } } http.send(params); 

Некоторые заголовки HTTP должны быть установлены вместе с любым запросом POST. Поэтому мы установили их в этих строках …

 http.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); http.setRequestHeader("Content-length", params.length); http.setRequestHeader("Connection", "close"); 

В приведенных выше строках мы в основном говорим, что передача данных в формате представления формы. Мы также даем длину параметров, которые мы отправляем.

 http.onreadystatechange = function() {//Call a function when the state changes. if(http.readyState == 4 && http.status == 200) { alert(http.responseText); } } 

Мы устанавливаем обработчик для события изменения состояния готовности. Это тот же обработчик, который мы использовали для метода GET. Здесь вы можете использовать http.responseText – вставить в div, используя innerHTML (AHAH), eval it (JSON) или что-нибудь еще.

 http.send(params); 

Наконец, мы отправляем параметры с запросом. Данный URL-адрес загружается только после вызова этой строки. В методе GET параметр будет иметь нулевое значение. Но в методе POST отправляемые данные будут отправляться как аргумент функции отправки. Параметр params был объявлен во второй строке как lorem=ipsum&name=binny – поэтому мы отправляем два параметра – «lorem» и «name» со значениями «ipsum» и «binny» соответственно.

В моем случае это было потому, что я использовал jQuery для отключения всех входов на странице перед использованием jQuery для отправки формы. Поэтому я изменил свой «отключить каждый вход, даже« скрытые »типы»:

 $(":input").attr("disabled","disabled"); 

«отключить только входные данные типа« кнопка »:

 $('input[type=button]').attr('disabled',true); 

Это было так, что пользователь не мог случайно нажать кнопку «пойти» дважды и вытащить нашу БД! Кажется, что если вы поместите атрибут «disabled» на вход типа «скрытый», их значения не будут отправлены, если форма будет отправлена!

Для меня .htaccess перенаправлялся, когда mod_rewrite не был установлен. Установите mod_rewite и все в порядке.

В частности:

 <IfModule !mod_rewrite.c> ErrorDocument 404 /index.php </Ifmodule> 

.

Если enable_post_data_reading параметр enable_post_data_reading это приведет к этому. Согласно документации:

enable_post_data_reading

Отключение этой опции заставляет $ _POST и $ _FILES не заполняться. Единственный способ прочитать postdata будет затем через фреймворк потока php: //. Это может быть полезно для запросов прокси или для обработки данных POST в памяти эффективным способом.

Я знаю, что с этого поста прошло какое-то время, но я думал, что буду способствовать тому, что проблема для меня.

Я получил следующую ошибку от Mod Security:

 Access denied with code 500 (phase 2). Pattern match "((select|grant|delete|insert|drop|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[AZ|az|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[AZ|az|0-9|\*| |\,]|UNION SELECT.*\'.*\'.*,[0-9].*INTO.*FROM)" at REQUEST_BODY. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "345"] [id "300013"] [rev "1"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] 

Как только я удалил конфигурацию безопасности мод для тестирования, все работало, как ожидалось. Теперь мне просто нужно изменить свои правила, чтобы оставаться в безопасности, но достаточно гибким для моих нужд 🙂

Люк

В дополнение к сообщению MRMage:

Мне пришлось установить эту переменную для решения проблемы, из-за которой исчезли некоторые переменные $_POST (с большим массивом> 1000 элементов):

 suhosin.request.max_vars = 2500 

« request », а не « post » было решением …

Возможно, это не самое удобное решение, но я понял, что если я установлю атрибут action формы в корневой домен, можно получить доступ к index.php и получить опубликованные переменные. Однако, если я устанавливаю перезаписанный URL как действие, он не работает.

Это похоже на то, что сказал @icesar.

Но я пытался отправлять материалы в api, расположенные в site/api/index.php , только для отправки на site/api поскольку он сам передается index.php . Это, однако, по-видимому, заставляет кое-что испортиться, так как мой $_POST был опустошен на лету. Вместо этого вместо этого была просто отправлена ​​на site/api/index.php .

Моя проблема заключалась в том, что я использовал <base> HTML <base> чтобы изменить базовый URL моего тестового сайта. Как только я удалил этот тег из заголовка, данные $_POST вернулись.

В моем случае (php-страница на сервере OVH mutualisé) enctype="text/plain" не работает ( $_POST и соответствующий $_REQUEST пуст), приводятся другие примеры ниже. `

 <form action="?" method="post"> <!-- in this case, my google chrome 45.0.2454.101 uses --> <!-- Content-Type:application/x-www-form-urlencoded --> <input name="say" value="Hi"> <button>Send my greetings</button> </form> <form action="?" method="post" enctype="application/x-www-form-urlencoded"> <input name="say" value="Hi"> <button>Send my application/x-www-form-urlencoded greetings</button> </form> <form action="?" method="post" enctype="multipart/form-data"> <input name="say" value="Hi"> <button>Send my multipart/form-data greetings</button> </form> <form action="?" method="post" enctype="text/plain"><!-- not working --> <input name="say" value="Hi"> <button>Send my text/plain greetings</button> </form> 

`

Подробнее здесь: method = "post" enctype = "text / plain" несовместимы?

Я думаю, проблема заключается в следующем: ваш (или ваш провайдер домена) PHP config блокирует метод POST.