Я пытаюсь сохранить коллекцию в моей базе данных RESTful с помощью Backbone.js с PHP SL Framework работает на моем сервере.
Вот моя коллекция:
Вот мой SLIM маршрут:
При звонке create() в моей коллекции я получаю предупреждение об устаревании в ответе сервера:
Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream instead. in Unknown on line 0
Я следовал этим инструкциям и сделал следующее:
Я добавил это перед моими маршрутами:
и из моего маршрута POST я попытался получить полезную нагрузку запроса следующим образом:
После этого изменения в моем коде ответ остался прежним …
РЕДАКТИРОВАТЬ
Ошибка возникает даже при пустом обратном вызове ….
Решение
В PHP 5.6 есть ошибка. Значение по умолчанию always_populate_raw_post_data является 0 , Это заставляет PHP выдавать предупреждения, даже если ваш код не использует $HTTP_RAW_POST_DATA , Некоторые утверждают, что это происходит при звонке header() после того, как какой-то текст уже был выведен. Пытаясь использовать ini_set() не помогает.
Вместо этого вы должны изменить конфигурацию непосредственно в php.ini.
связанные с обсуждение во внутренностях PHP.
Другие решения
В основном вы можете решить Automatically populating $HTTP_RAW_POST_DATA is deprecated. ошибка в двух отношениях,
Изменение файла always_populate_raw_post_data на -1 php.ini решит проблему. Однако это становится проблемой, когда у вас недостаточно контроля над файлом php.ini. Вы можете думать о виртуальном хостинге.
Изменение файла .htaccess внутри вашего каталога приложений. Это даст изолированный контроль только над вашей заявкой. Это не повлияет ни на APACHE, ни на PHP выполнения других приложений.
php_value always_populate_raw_post_data -1
И я бы порекомендовал второй подход. Так как он позволяет разместить ваше приложение как на виртуальном хостинге, так и на выделенном хостинге
Вы можете запросить данные POST через объект запроса, поступающий из Slim.
Я переключился на PHP 5.6.0, и теперь везде получаю следующее предупреждение:
Хорошо, я полагаюсь на некоторые устаревшие функции. За исключением того, что я этого не делаю!
- Я никогда не использовал эту переменную ни в одном из моих скриптов. Честно говоря, я даже не подозревал, что он существует.
- phpinfo() показывает, что у меня always_populate_raw_post_data установлено значение 0 (отключено). Итак, что происходит?
Я не хочу «избегать предупреждения», установив это значение равным -1. Это просто скроет предупреждение, и у меня все еще будет устаревшая конфигурация. Я хочу решить проблему в ее источнике и знать, почему PHP считает, что включение HTTP_RAW_POST_DATA включено.
Оказывается, мое понимание сообщения об ошибке было неправильным. Я бы сказал, что у него очень плохой выбор слов. Google googling показал мне, что кто-то еще неправильно понял сообщение точно так же, как я сделал — см. PHP-ошибка # 66763.
После совершенно бесполезного «Это то, как хотели это RM». ответ на эту ошибку Майка, Тайраэль объясняет, что установка этого параметра на «-1» не означает, что предупреждение просто исчезнет. Он поступает правильно, т.е. Полностью отключает заполнение переменной преступника. Оказывается, что при условии, что он установлен в 0 STILL, он заполняет данные при некоторых обстоятельствах. Расскажите о плохом дизайне! Чтобы привести PHP RFC:
Измените параметр always_populate_raw_post_data INI, чтобы принять три значения вместо двух.
- -1: поведение мастера; никогда не заполняют $GLOBALS [HTTP_RAW_POST_DATA]
- 0/off/whatever: поведение BC (заполняется, если тип контента не зарегистрирован, или метод запроса отличен от POST)
- 1/on/yes/true: поведение BC (всегда заполнять $GLOBALS [HTTP_RAW_POST_DATA])
Итак, да, установив его на -1, вы не только избегаете предупреждения, как и сообщение, но оно также, наконец, отключает заполнение этой переменной, чего я хотел.
Некоторое время, пока я не наткнулся на эту ошибку. Положите мой ответ всем, кто может наткнуться на этот вопрос.
Ошибка означает, что вы отправляете пустой запрос POST. Эта ошибка обычно встречается в HTTPRequests без переданных параметров. Чтобы избежать этой ошибки, вы всегда можете добавить параметр к POST без изменения php.ini.
Я столкнулся с той же проблемой на сервере nginx (DigitalOcean) — все, что мне нужно было сделать, это войти в систему как root и изменить файл /etc/php5/fpm/php.ini .
Чтобы найти строку с always_populate_raw_post_data , я сначала запускаю grep :
Это вернуло строку 704
Затем просто откройте php.ini на этой строке с помощью редактора vi :
Удалите двоеточие, чтобы раскомментировать его и сохранить файл :wq
Наконец, перезагрузите сервер, и ошибка исчезла.
Если вы используете WAMP.
вы должны добавить или раскомментировать свойство always_populate_raw_post_data в php.ini и установить его значение -1 . В моем случае php.ini находится в:
, но если вы все еще получаете предупреждение (как и я)
Вы также должны установить always_populate_raw_post_data = -1 в phpForApache.ini :
Если вы не можете найти этот файл, откройте окно браузера и перейдите к:
и найдите значение Загруженного файла конфигурации. В моем случае php.ini , используемый WAMP, находится в:
C:wamp64inapacheapache2.4.23inphp.ini (символическая ссылка на C:wamp64inphpphp5.6.25phpForApache.ini)
Наконец, перезапустите WAMP (или перезапустите все службы)
в php.ini(строка # 703) и перезапуск служб APACHE помогают мне избавиться от сообщения в любом случае
Если файл .htaccess не доступен, создайте его в корневой папке и пропустите эту строку кода.
Поместите это в файл .htaccess (хорошо протестированный для API)
Для тех, кто все еще борется с этой проблемой после изменения php.init, как предполагает принятый ответ. Поскольку ошибка возникает, когда алиасовая петиция выполняется через POST без какого-либо параметра, все, что вам нужно сделать, это изменить метод отправки на GET .
Еще одна опция, если вы хотите сохранить метод POST по какой-либо причине, — это добавить пустой объект JSON в ajax petititon.
Я получил это сообщение об ошибке при отправке данных из HTML-формы (метод Post). Все, что мне нужно было сделать, это изменить кодировку в форме с «text/plain» на «application/x-www-form-urlencoded» или «multipart/form-data». Сообщение об ошибке очень вводило в заблуждение.
К сожалению, этот ответ @EatOng здесь не правильный. Прочитав его ответ, я добавил фиктивную переменную в каждый запрос AJAX, который я запускал (даже если у некоторых из них уже было несколько полей), чтобы быть уверенным, что ошибка никогда не появится.
Но только сейчас я столкнулся с той же чертовой ошибкой в PHP. Я дважды подтвердил, что отправил некоторые данные POST (некоторые другие поля тоже вместе с фиктивной переменной). Версия PHP 5.6.25 , значение always_populate_raw_post_data равно 0 .
Кроме того, когда я отправляю запрос application/json , PHP не json_decode() его до $_POST , скорее, мне нужно json_decode() — необработанное тело запроса POST, доступное через php://input .
В ответе @rr- цитирует,
0/выкл./Что угодно: поведение BC (заполняется, если тип содержимого не зарегистрирован или метод запроса отличается от POST).
Поскольку метод запроса точно POST, я предполагаю, что PHP не распознал/не понравился мой запрос Content-Type: application/json (опять же, почему??).
ОПЦИЯ 1:
Отредактируйте файл php.ini вручную и установите для переменной виновника значение -1 , как предлагают многие ответы здесь.
ВАРИАНТ 2:
Это ошибка PHP 5.6. Обновите PHP.
ВАРИАНТ 3:
Как @user9541305 ответил здесь, изменение запроса Content-Type AJAX на application/x-www-form-urlencoded или multipart/form-data заставит PHP заполнить $_POST из тела POSTed (потому что PHP любит/распознает этот content-type заголовков !?).
ВАРИАНТ 4: ПОСЛЕДНИЙ КУРОРТ
Ну, я не хотел менять Content-Type AJAX, это вызвало бы много проблем при отладке. (Chrome DevTools прекрасно просматривает POST-переменные запросов JSON.)
Comments
Copy link Quote reply
mattab commented Oct 19, 2014
Our build fails on 5.6 because of this warning.
It’s quite annoying and I find lots of people online with the problem.
I’m not sure the proper way to fix this. a search in our code shows we don’t use $HTTP_RAW_POST_DATA .
Maybe we really need to edit php.ini and set always_populate_raw_post_data to -1 ? (in this case we’d have to add system check to check users have set it to -1).
- Bug report: >
This comment has been minimized.
Copy link Quote reply
mnapoli commented Oct 19, 2014
that would solve the problem if we don’t use the variable that was deprecated (if I understand it correctly).
What I don’t understand though is that the warning appears regardless of whether an application uses that variable… I’ve had that warning on very small scripts that didn’t use the variable at all. I find it weird that PHP 5.6 ships like that, maybe I’m missing something.
This comment has been minimized.
Copy link Quote reply
mattab commented Oct 19, 2014
I find it weird that PHP 5.6 ships like that, maybe I’m missing something.