Март 14 2006

Применимость методов GET и POST

Категория: HTTP-протоколgugglegum @ 16:56

Я рискую быть обвиненным в изложении каких-то очевидных и общеизвестных фактов, но мои скромные наблюдения говорят о том, что подавляющее большинство веб-разработчиков не знают где допустимо использование ссылок или форм с методом GET, а где нет. Считайте это небольшим ликбезом.

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

Вследствие этого вы часто можете видеть веб-интерфейсы, где какие-то манипуляции с данными осуществляются обычными ссылками. Например, ссылки «Удалить», «Скрыть», «Очистить» и т.п. Чем это плохо? — спросите вы. Плохо это тем, что HTTP методы запроса GET и POST имеют принципиально различное семантическое значение.

Обратимся к спецификации HTTP/1.1 (RFC-2616):

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Здесь явным образом говорится, что методы GET и HEAD не должны иметь смысл действия, отличного от получения запрашиваемой информации и потому эти методы называются «безопасными». То есть их всегда безопасно выполнять без какого-либо вреда.

Если вы используете ссылки для выполнения каких-то операций с данными, поисковый робот может пойти по вашей ссылке и выполнить эти операции. Вы можете возразить тем, что поисковый робот никогда не попадет в интерфейс, защищенный паролем, что ж, другой пример:

Может появиться плагин для браузера, который автоматически preload’ит все ссылки на странице, чтобы когда пользователь нажмет какую-либо из них — ему не пришлось ждать загрузки страницы. Конечно, в российских условиях это расточительство, но где-нибудь за границей, где у большинства пользователей выделенный канал, ограниченный лишь скоростью канала — это был бы очень даже полезный плагин.

Также не стоит забывать о кэшировании (Expiration Model), которое если не запрещено, то повторный переход по ссылке, которая предполагает выполнение действия, может выполниться без обращения к серверу, то есть действие не будет выполнено. К слову, ответы на POST-запросы никогда не кэшируются.

Кроме этого, я считаю хорошим тоном завершать успешное выполнение POST запроса редиректом (который выполняется методом GET) на страницу результата. Пользователь не должен оставаться на странице, полученной методом POST, дольше, чем это необходимо. Проблема POST в том, что пользователь может нажать «Обновить» и действие будет выполнено повторно, а это может привести к нежелательным последствиям.

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

Добавлено 07.09.2007:

Кстати, на счет плагина… Я оказался прав и такой плагин действительно появился — Fasterfox. В описании его возможностей явным образом говорится:

Prefetch Links
Dynamic speed increases can be obtained with Fasterfox’s unique prefetching mechanism, which recycles idle bandwidth by silently loading and caching all of the links on the page you are browsing.

8 отзывов на “Применимость методов GET и POST”

  1. Asset says:

    пожалуйста,напишите как можно общире.я только изучаю web…

  2. Игорь says:

    “интерфейсы, где какие-то манипуляции с данными осуществляются обычными ссылками. Например, ссылки «Удалить»,”
    если я правельно понял то к адресу в ссыке приписывают:
    ?name=1 и.т.д. А как подругому организовать меню если нужно чтобы данные перешли в CGI скрипт и он на основе этих данных сгенерировал страницу?

  3. gugglegum says:

    Используй mod_rewrite. Он может как видоизменять исходный URL, так и полностью скармливать скрипту любой URL внутри какого-то пути так, чтобы скрипт сам его парсил и определял что с ним делать дальше. Но к теме данного поста и моей цитате это никак не относится.

  4. Андрей says:

    Подскажите пожалуйста, а лучше опишите детально..как сделать страничку типа www.vash_sait.ru/id123
    какое она имеет расширение? Как вообще забить этот номер и написать данный тег?

  5. gugglegum says:

    Андрей, это совсем из другой темы. Рекомендую погуглить на тему “apache mod_rewrite php”

  6. Иван says:

    Было бы интересно еще почитать о реализации методов PUT, DELTE и т.п. Что ссылками пользоваться не дело - ясно, а как поступать дальше - нет.

  7. Mugen says:

    > Проблема POST в том, что пользователь может нажать «Обновить» и действие будет выполнено повторно, а это может привести к нежелательным последствиям.

    Если хочешь избежать ошибок после обновления веб-страницы, помести в конец скрипта обработки
    header(”Location: страница_на_которой_пишешь.php”);
    Она будет перекидывать тебя на эту же страницу, “стерая” переменные POST.

  8. system says:

    Приношу свои извинения.
    Как и в большинстве случаев, ошибки возникают из-за невнимательности.
    Вместо того, чтобы написать mhetod я написал metod.

Напишите что Вы об этом думаете


*


*


rel=nofollow включен, спам не поднимет Page Rank Вашего сайта



Anti-Spam Image
Введите этот код, чтобы подтвердить, что вы человек
*

* — Обязательно для заполнения

Перейти на главную страницу