Почему вы должны удалять, используя HTTP POST или DELETE, а не GET?

Question

Я работал над учебными пособиями Microsoft по ASP.NET MVC, заканчивающимися на этой странице

http://www.asp.net/learn/mvc/tutorial-32-cs.aspx

В нижней части этой страницы делается следующее заявление:

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

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

Редактировать

Википедия гласит следующее:

Некоторые методы (например, HEAD, GET, OPTIONS и TRACE) определены как безопасные, что означает, что они предназначены только для поиска информации и не должны изменять состояние сервера.

Напротив, такие методы, как POST, PUT и DELETE, предназначены для действий, которые могут вызвать побочные эффекты на сервере

Answer 1

Ответ Джона Скита - канонический ответ. Но: Предположим, у вас есть ссылка:

href = "\myApp\DeleteImportantData.aspx?UserID=27"

а гугл-бот приходит и индексирует вашу страницу? Что происходит потом?

Answer 2

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

С HTTP 1.1 RFC 2616

Исполнители должны знать, что Программное обеспечение представляет пользователя в их взаимодействия через Интернет, и следует быть осторожным, чтобы позволить пользователю быть в курсе любых действий, которые они могут взять который может иметь неожиданный значение для себя или других.

В частности, конвенция была Установлено, что ПОЛУЧИТЬ и ГОЛОВУ методы не должны иметь Важность принятия действий других чем поиск. Эти методы должны считаться "безопасным". Это позволяет пользователю агенты для представления других методов, такие как POST, PUT и DELETE, в особый способ, так что пользователь сделан осознавая тот факт, что возможно запрашивается небезопасное действие.

Естественно, невозможно убедитесь, что сервер не генерировать побочные эффекты в результате выполнение запроса GET; по факту, некоторые динамические ресурсы считают, что особенность. Важное различие вот что пользователь не запрашивал побочные эффекты, поэтому не может нести ответственность за них.

Answer 3

Помимо пуристических проблем, связанных с идемпотентностью, есть и практическая сторона: пауки / боты / сканеры и т.д. будут следовать гиперссылкам. Если у вас есть действие «удалить» как гиперссылка, которая выполняет GET, то Google может весело удалить все ваши данные. Смотрите « Паук Судьбы ».

С постами это не риск.

Answer 4

Другой пример ..

http://example.com/admin/articles/delete/2

Это удалит статью, если вы вошли в систему и имеете необходимые привилегии. Если ваш сайт принимает комментарии, например, и пользователь отправляет эту ссылку в виде изображения; вот так:

<img src="http://example.com/admin/articles/delete/2" alt="This will delete your article."/>

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

Вы можете даже не заметить, не глядя на исходный код, так как большинство браузеров ничего не показывают, если не могут найти изображение.

Надеюсь, что это имеет смысл.

Answer 5

Пожалуйста, смотрите мой ответ здесь . Это в равной степени относится и к этому вопросу.

• Предварительная выборка: Многие веб-браузеры будут использовать предварительную выборку. Что значит что он загрузит страницу перед вами нажмите на ссылку. Предвидя, что Вы перейдете по этой ссылке позже.
• Боты: Есть несколько ботов, которые сканируют и индексируют интернет для Информация. Они будут только выпускать GET Запросы. Вы не хотите удалять что-то из запроса GET для этого причина.
• Кэширование: Запросы GET HTTP не должны изменять состояние, и они должны быть идемпотентными. Идемпотент означает, что выдача запроса один раз или выдача его несколько раз дает один и тот же результат. То есть Там нет никаких побочных эффектов. За По этой причине GET HTTP-запросы тесно связаны с кэшированием.
• Стандарт HTTP говорит так : Стандарт HTTP говорит, что каждый метод HTTP за. Несколько программ построены для использовать стандарт HTTP, и они предполагают, что ты будешь использовать его таким, какой ты есть должен. Так у вас будет неопределенное поведение от убийства случайные программы, если вы не будете следовать.

Answer 6

В дополнение к паукам и запросам, которые должны быть идемпотентными, существует также проблема безопасности с запросами get. Кто-то может легко отправить вашим пользователям электронное письмо с

<img src="http://yoursite/Delete/Me" />

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

Answer 7

Об этой теме (использование методов HTTP), я рекомендую прочитать этот блог: http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/

Это на самом деле противоположная проблема: почему бы не использовать POST, если данные не изменены.

Answer 8

Помимо всех веских причин, упомянутых здесь, GET-запросы могут регистрироваться сервером-получателем, например, в access.log. Если вы отправите в запросе конфиденциальные данные, такие как пароли, они будут зарегистрированы как открытый текст.

Даже если они хешированы / засолены для безопасного хранения БД, их может обнаружить взлом (или кто-то, глядя через плечо IT-парня) Такие данные должны идти в теле сообщения POST.

Answer 9

Допустим, у нас есть приложение для интернет-банкинга, и мы заходим на страницу перевода. Зарегистрированный пользователь решает перевести 10 долларов на другую учетную запись.

Нажатие на кнопку отправки перенаправляет (как запрос GET) на https://my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j

Но интернет-соединение медленное и / или сервер (ы) занят (ы), поэтому после нажатия кнопки отправки новая страница загружается медленно.

Пользователь расстроен и начинает яростно нажимать F5 (страница обновления). Угадай, что будет? Произойдет несколько передач, возможно, при очистке учетной записи пользователя.

---

Теперь, если запрос сделан как POST (или что-то еще, кроме GET), первая F5 (страница обновления), которую пользователь сделает браузером, мягко спросит: «Вы уверены, что хотите это сделать? бла бла бла] ... "

Answer 10

Другая проблема с GET заключается в том, что команда переходит в адресную строку браузера. Поэтому, если вы обновите страницу, вы снова введете команду, будь то «удалить последние данные», «отправить заказ» или аналогичные.