





Использование $ _REQUEST открывает некоторые векторы атаки для вашего приложения, где переменные могут быть перезаписаны там, где вы бы этого не хотели.
Также рассмотрите порядок GPC (Get, Post, Cookie), в котором будет заполнен $ _REQUEST.
то есть запрос с:
$_GET['foo'] = 'bar'
$_POST['foo'] = 'baz'
приведет к
$_REQUEST['foo'] == 'bar'
Это только я, или POST будет идти после GET в вашем примере, поэтому содержимое переменной будет перезаписано? Не уверен, поэтому и спрашиваю ...
Вы уже дали один из ответов, поэтому я дам другой:
Это скорее стилистический выбор. Например, обычно вы не хотите, чтобы информация, которая изменяет состояние на сервере, кэшировалась, поэтому вы, вероятно, захотите ограничить ее переменными $_POST.
Отличный ответ! Я надеюсь увидеть их больше.
часто упоминаемая небезопасность $ _REQUEST является подделкой. все это способы получить данные от пользователя, у которого есть незащищенная машина. вам всегда нужно дезинфицировать ввод, поэтому нет никакого реального преимущества в безопасности от использования любого из них.
это важно только в том случае, если вы по-разному используете значения с одинаковыми именами на разных каналах. в этом случае вам все равно следует переименовать некоторые из них.
Совершенно верно, люди хотят кричать, что запрос - это большая дыра в безопасности, но даже GET и POST одинаково небезопасны, в них легко вставлять непослушные биты, вам нужно всегда дезинфицировать все данные, даже то, что поступает из вашей базы данных.
Besides the fact that $_REQUEST reads from cookies
Помимо того факта, что он не определен (он настраивается на уровне установки), проблема с использованием $_REQUEST заключается в том, что он чрезмерно упрощает вещи. Существует (или должна быть) семантическая разница между запросом GET и запросом POST. Таким образом, для вашего приложения должно иметь значение, получаете ли вы ввод из того или иного источника. Так определяется протокол HTTP, поэтому, игнорируя его, вы подрываете протокол, что делает ваше приложение менее совместимым. Это аргумент того же типа, который можно использовать для использования семантической разметки HTML, а не разметки, ориентированной на представление. Или, в более общем плане, следование намерениям протокола, а не просто выполнение того, что работает в конкретной ситуации.
Here's one I've just found: Когда и почему следует использовать $ _REQUEST вместо $ _GET / $ _POST / $ _COOKIE?. Мне жаль, что я не нашел его раньше, поэтому не стал бы задавать вопрос ...
Я использую $ _REQUEST, когда мне просто нужно, чтобы определенные данные от пользователя возвращали определенные данные.
Никогда не используйте $ _REQUEST, если запрос будет иметь побочные эффекты. Запросы, которые вызывают побочные эффекты, должны быть POST (по семантическим причинам, а также из-за базового материала CSRF ложный тег img может поразить любую конечную точку GET без ведома пользователя).
$ _GET следует использовать, когда GETing или POSTing на страницу будут давать разные результаты.
Поздравляем, вы только что получили свой первый принятый ответ :) Добро пожаловать на stackoverflow.com!
HTTP GET семантически предназначен для использования для выборки страницы, в то время как POST можно утверждать, что при использовании можно ожидать, что какое-то состояние изменится.
Например, ожидается, что многократное использование GET с одними и теми же параметрами даст одни и те же результаты, а при использовании POST - нет.
Не использовать POST, когда вы должны уступить место проблемам. Я думаю, что библиотеки AJAX Ruby on Rails использовали GET вместо POST и приводили к потере большого количества данных, когда их касались веб-пауки.
Следовательно, вам, вероятно, следует избегать использования $ _REQUEST. Вы должны знать цели того, что делает страница, и решить, как ответить на запрос GET и как ответить на запрос POST.
Обратите внимание, что вы можете изменить порядок заполнения переменной запроса, если вы управляете php.ini.