Действие формы с параметрами — параметры отсутствуют в $_GET или $_POST

Я работаю над повторной реализацией REST API, для которого у клиента нет исходного кода и он теряет доступ к серверу...

Я обнаружил, что вызывающий абонент отправляет сообщения, но без опубликованных данных. Все параметры указаны в URL или какое действие было бы, если бы это была форма публикации.

Вот так:

"POST http://foo.com/api/rest/?method=users.add_user&token=foo&section=bar&group=baz HTTP/1.1" 200 605 "-" "-"

К моему удивлению, эти параметры отсутствуют ни в $_GET, ни в $_POST, а доступны только в $_REQUEST.

Я что-то упустил здесь? Почему они не находятся в $_GET как часть доступного URL-адреса? Очевидный ответ: «потому что это POST, поэтому GET не определен»?

Может ли кто-нибудь просветить меня о моих неправильных представлениях об этих суперглобалах?


request php get post superglobals
person jerrygarciuh    schedule 16.02.2012    source источник
comment
Это долгий путь, но $_REQUEST обычно также включает $_COOKIE. Есть ли шанс, что эти же ключи устанавливаются в файлах cookie клиента?   -  person Andrew Ensley    schedule 16.02.2012
comment
Вы знаете, что указание параметров в URL-адресе — это способ GET для форм, а способ POST отправит их в тело http? Я полагаю, что это может быть связано с этим (хотя я недостаточно хорошо знаю php). Что произойдет, если вы используете GET в качестве метода?   -  person ZPiDER    schedule 16.02.2012
comment
@ZPiDER - сообщение исходит из удаленного сценария, не находящегося под моим контролем, но мои вопросы не касаются отладки этого процесса.   -  person jerrygarciuh    schedule 16.02.2012
comment
@ Андрей, я так не думаю. $_GET и $_POST полностью пусты, а $_REQUEST содержит все переменные из URL...   -  person jerrygarciuh    schedule 16.02.2012

Ответы (1)


arrow_upward
2
arrow_downward

$_GET и $_POST пусты, потому что вы используете протокол POST, но отправляете переменные через метод GET (кодируя их в URL-адресе).

PHP находит используемый метод POST, поэтому он ничего не устанавливает для информации в переменной $_GET, а затем анализирует переменные, отправленные в данных POST формы, в переменную $_POST, т. е. ничего.

С другой стороны, переменная $_REQUEST работает по другой механике, где она будет анализировать все переменные из запроса, независимо от того, получены ли они из файлов cookie, составных данных, публикации, получения и т. д. Вот почему вы видите их там.

Как правило, скрипты и приложения работают с данными $_REQUEST в любом случае, так как это гораздо более краткий набор всех данных, и, поскольку технически вы не можете иметь данные GET и POST в одном и том же запросе, вам не нужно беспокоиться о конфликте между наборы данных.

person Brian    schedule 16.02.2012
comment
Большое Вам спасибо. Это именно то, чему я не мог научиться до сегодняшнего дня. Весьма признателен! - person jerrygarciuh; 16.02.2012
comment
Тогда почему, когда я отправляю форму somepage.php?key=blah, даже если нет данных POST, $_GET['key'] есть? - person Niet the Dark Absol; 16.02.2012
comment
С одной оговоркой. Иногда вам явно нужна переменная только в том случае, если она была правильно отправлена ​​POST. В этом случае предпочтительнее проверять $_POST и игнорировать $_REQUEST. Обычно это происходит, когда вы предпринимаете деструктивные действия (такие, которые каким-то образом изменяют данные), и вы действительно не хотите, чтобы Google вмешивался. - person NotMe; 16.02.2012
comment
@Kolink Я видел случаи, когда я получаю переменные GET из запроса POST на определенных серверах/конфигурациях и TBH. Я никогда не удосужился разобраться, почему, поскольку эти случаи были упс, я не изменил экземпляры метода формы, и я этого не сделал. все равно, лол, но да, я сам видел редкие случаи этого. Я предполагаю, что это ошибка, но поскольку большинство людей правильно формулируют свои запросы при кодировании и используют соответствующий суперглобал в скрипте, я думаю, что это просто случай, когда большинство людей этого не замечают, а те, кто это замечает, исправляют свою ошибку и не меня не волнует, что PHP сошел с ума :P - person Brian; 16.02.2012