Почему вы должны удалять, используя HTTP POST или DELETE, а не GET?
Если я работаю с элементами
$(".no-svg img").each(function() {
var $this = $(this);
if ($this.attr("src").indexOf(".svg") > -1) {
var isSvg = $this.attr("src").toString();
var isPng = isSvg.replace(".svg", ".png");
$this.attr("src", isPng);
}
});
1) Я создаю .png версии каждого .svg-файла. 2) Modernizr предоставляет элементу html класс .no-svg, если он обнаруживает, что поддержка .svg отсутствует. 3) jQuery меняет местами расширения файлов. .indexOf(".svg") проверяет, содержится ли строка ".svg" в пределах значения src, возвращая -1, если она не находит его и положительное целое число, если оно выполняется. Если он найдет ".svg", вся цепочка src втягивается в isSvg, а .replace() свопы .svg для .png и сохраняет результат как isPng, который затем устанавливается как значение src.
8 ответов
Ответ Джона Скита - канонический ответ. Но: Предположим, у вас есть ссылка:
href = "\myApp\DeleteImportantData.aspx?UserID=27"
, и гугл-бот приходит и индексирует вашу страницу? Что происходит потом?
GET обычно не имеет побочных эффектов - другими словами, он не меняет состояние. Это означает, что результаты могут кэшироваться, закладки могут создаваться безопасно и т. Д.
С разработчикам HTTP 1.1 RFC 2616
следует знать, что Программное обеспечение представляет пользователя в их взаимодействия через Интернет, и следует быть осторожным, чтобы позволить пользователю быть в курсе любых действий, которые они могут взять который может иметь неожиданный значение для себя или других.
В частности, конвенция была Установлено, что ПОЛУЧИТЬ и ГОЛОВУ методы не должны иметь Важность принятия действий других чем поиск. Эти методы должны считаться "безопасным". Это позволяет пользователю агенты для представления других методов, такие как POST, PUT и DELETE, в особый способ, так что пользователь сделан осознавая тот факт, что возможно запрашивается небезопасное действие.
Естественно, невозможно убедитесь, что сервер не генерировать побочные эффекты в результате выполнение запроса GET; на самом деле, некоторые динамические ресурсы считают, что характерная черта. Важное различие вот что пользователь не запрашивал побочные эффекты, поэтому не могут нести ответственность за них.
Помимо пуристических проблем, связанных с идемпотентностью, есть практическая сторона: пауки / боты / сканеры и т. д. будут следовать гиперссылкам. Если у вас есть действие «удалить» как гиперссылка, которая выполняет GET, то Google может весело удалить все ваши данные. См. « Паук Судьбы ».
С постами это не риск.
Пожалуйста, смотрите мой ответ здесь . Это в равной степени относится и к этому вопросу.
- Предварительная выборка: Многие веб-браузеры будут использовать предварительную выборку. Что значит что он загрузит страницу перед вами нажмите на ссылку. Предвидя, что Вы перейдете по этой ссылке позже.
- Боты: Есть несколько ботов, которые сканируют и индексируют интернет для Информация. Они будут только выпускать GET Запросы. Вы не хотите удалять что-то из запроса GET для этого причина.
- Кэширование: Запросы GET HTTP не должны изменять состояние, и они должны быть идемпотентными. Идемпотент означает, что выдача запроса один раз или выдача его несколько раз дает один и тот же результат. Т.е. побочных эффектов нет. Для По этой причине GET HTTP-запросы тесно связаны с кэшированием.
- Стандарт HTTP говорит так : Стандарт HTTP говорит, что каждый метод HTTP для. Несколько программ построены для использовать стандарт HTTP, и они предполагают, что вы будете использовать его таким, какой вы есть должен. Так у вас будет неопределенное поведение от убийства случайные программы, если вы не подписаны.
В дополнение к паукам и запросы должны быть идемпотентными, есть также проблема безопасности с запросами get. Кто-то может легко отправить вашим пользователям электронное письмо с
<img src="http://yoursite/Delete/Me" />
в тексте, и браузер с радостью согласится и попытается получить доступ к ресурсу. Использование POST не является лекарством от таких вещей (поскольку вы можете довольно легко собрать пост в javascript), но это хорошее начало.
Об этой теме (использование методов HTTP), я рекомендую прочитать эту запись в блоге: http://blog.codevader.com / 2008/11/02 / why-learning-http-do-question /
Это на самом деле противоположная проблема: почему не использовать POST, если данные не изменены.
Допустим, у нас есть приложение для интернет-банкинга, и мы заходим на страницу перевода. Зарегистрированный пользователь решает перевести 10 долларов на другую учетную запись.
Нажатие на кнопку отправки перенаправляет (как запрос GET) на https://my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j
Но интернет-соединение медленное и / или сервер (ы) занят (ы), поэтому после нажатия кнопки отправки новая страница загружается медленно.
Пользователь расстроен и начинает яростно нажимать F5 (обновить страницу). Угадай, что будет? Может произойти больше чем одна передача, возможно, опустошая учетную запись пользователя.
Теперь, если запрос сделан как POST (или что-то еще, кроме GET), первая F5 (страница обновления), которую пользователь заставит браузер, мягко спросит " ты уверен, что хочешь это сделать? Может иметь побочные эффекты [бла бла бла] ... "
Другая проблема с GET заключается в том, что команда переходит в адресную строку браузера. Поэтому, если вы обновляете страницу, вы снова вводите команду, будь то «удалить последний материал», «отправить заказ» или подобное.