Хорошо, я знаю разницу в назначении. GET - получить некоторые данные. Сделайте запрос и верните данные. POST должен использоваться для операций CRUD, кроме чтения, я считаю. Но когда дело доходит до этого, действительно ли сервер заботится о том, получает ли он GET или POST?GET против POST действительно ли это имеет значение?
Поскольку вы писали серверное программное обеспечение (предположительно), то это волнует, если вы сообщите ему об этом. Если вы обрабатываете данные POST и GET одинаково, то нет, это не так.
Однако обозреватель определенно заботится. Обновление или щелчок назад к странице, которую вы получили в ответ на POST, выдает, например, небольшую подсказку «Вы уверены, что хотите отправить данные снова».
Что еще более важно, вы можете использовать шаблон Post/Redirect/Get, чтобы люди не могли случайно повторить действия. – Wedge
Это можно обойти, если ваш код, обрабатывающий запрос POST, никогда ничего не отображает, а перенаправляет на страницу, которая делает. См. Http://en.wikipedia.org/wiki/Post/Redirect/Get –
Конечно. И это в значительной степени мое мнение. С точки зрения браузера важно, отправляете ли вы данные через POST или GET, и поэтому они должны обрабатываться сервером по-разному. Я бы не назвал это «обходным путем», поскольку это означает, что поведение браузера является ошибкой. Он работает таким образом по вполне веской причине, и «обходной путь» - совершенно логичный способ справиться с этим. – jalf
Следует ли иметь возможность сделать закладку на итоговую страницу? Другое дело, что некоторые браузеры/серверы неправильно ограничивают длину URI GET.
Редактировать: исправленное ограничение длины длины символа - спасибо ars!
jbruce211: Это предел, основанный на реализациях (например, браузерах или http-серверах). Это не является пределом, присущим GET для спецификации HTTP. Из спецификации: «Протокол HTTP не устанавливает априорного ограничения длины URI. Серверы ДОЛЖНЫ иметь возможность обрабатывать URI любого ресурса, который они обслуживают, и ДОЛЖНЫ иметь возможность обрабатывать URI неограниченной длины, если они предоставлять формы на основе GET, которые могут генерировать такие URI ». http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html – ars
Нет, они не должны за исключением @ jbruce2112 ответа и загрузки файлов, требующих POST.
GET имеет ограничения на стороне браузера. Например, some browsers ограничивает длину запросов GET.
Я думаю, что более подходящий ответ, вы можете в значительной степени сделать то же самое с обоими. Однако дело не столько в предпочтении, сколько в правильном использовании . Я бы порекомендовал вам использовать GET и POST как они были предназначено для использования.
Это происходит, если поисковая система сканирует страницу, так как они будут делать запросы GET, но не POST. Скажем, у вас есть ссылка на странице:
http://www.example.com/items.aspx?id=5&mode=delete
Без какой-то проверки авторизации выполняется до удаления, вполне возможно, что Googlebot может come in and delete items с вашей страницы.
Отличная находка Брайана, я искал эту точную статью для ссылки! –
Даже с разрешения злоумышленники могут отправить электронное письмо с кому-то, кто уже вошел в систему. –
Paco
@Paco: Если ваш браузер загружает этот img, он будет использовать GET. Веб-сервер НЕ должен делать такие действия, как «удалить» на основе запроса GET именно по этой причине. Ответственность веб-сервера заключается в том, чтобы обеспечить выполнение серьезных действий только через запросы POST. – abelenky
Это зависит от программного обеспечения на сервере. Некоторые библиотеки, такие как CGI.pm в perl, обрабатывают оба по умолчанию. Но бывают ситуации, когда вы более или менее должны использовать POST вместо GET, по крайней мере для того, чтобы нажимать данные на сервер. Большие объемы данных (где соответствующий URL-адрес GET станет слишком длинным), двоичные данные (во избежание проблем с кодированием/декодированием), многочастные файлы, не прошедшие анализ заголовков (для непрерывного обновления до AJAX-стиля ...) и аналогичных ,
Сервер технически не может заботиться так или иначе о том, какой запрос он получает. Он будет слепо выполнять любой запрос, проходящий через провод.
В чем проблема. Если у вас есть действие, которое уничтожает или изменяет данные в действии GET, Google будет разорвать ваш сайт, когда он сканирует индексирование.
Сервер обычно не заботится. Но, как вы упомянули, это в основном для соблюдения передовых практик. Сторона клиента также имеет значение. Как уже упоминалось, вы не можете обычно добавлять закладку на страницу POST'а, а некоторые браузеры имеют ограничения на длину URL-адреса для действительно длинных запросов GET.
Если вы используете запрос GET для изменения состояния на заднем плане, вы рискуете иметь плохие вещи, если веб-браузер каким-то образом пересекает ваш сайт.Назад, когда вики впервые стали популярными, были ужасные истории о удалении целых сайтов, потому что функция «удалить страницу» была реализована как запрос GET с катастрофическими результатами, когда робот Googlebot пришел в нокаут ...
Поскольку GET предназначен для указав ресурс, который вы хотите получить, в зависимости от точного программного обеспечения на стороне сервера, веб-сервер (или балансировщик нагрузки перед ним) может иметь ограничение размера для запросов GET для предотвращения атак типа «отказ в обслуживании» ...
" Используйте GET, если: взаимодействие больше похоже на вопрос (то есть, это безопасная операция, такая как запрос, операция чтения или поиск). "
«Использовать POST, если: взаимодействие больше похоже на заказ, или взаимодействие изменяет состояние ресурса таким образом, чтобы пользователь воспринимал (например, подписку на услугу) или пользователь считался ответственным для результатов взаимодействия ».
Согласно HTTP RFC, GET не должны иметь каких-либо побочных эффектов, в то время как POST может иметь побочные эффекты.
Самый простой пример этого состоит в том, что GET не подходит ни для чего, как покупка-транзакция, или для публикации статьи в блоге, тогда как POST подходит для действий, которые имеют последствия.
К RFC вы можете удерживать пользователя, ответственного за действия, выполняемые POST (например, покупка), но не для действий GET. «Боты всегда используют GET по этой причине.
От RFC 2616, 9.1.1:
9.1.1 Безопасные методы
Implementors должны знать, что программное обеспечение представляет пользователю в
их взаимодействия через Интернет, и должны быть осторожными чтобы пользователь знал о любых действиях, которые могут быть приняты , которые могут иметь
u незначащее значение для себя или другие.В частности, Конвенция было установлено, что GET и
методы голова не должна иметь значение принимает меры
, кроме поиска. Эти методы следует считать «безопасными». Это позволяет агентам пользователя представлять другие методы, такие как POST, PUT и DELETE , особым образом, так что пользователь становится известно о том, что ? Возможно небезопасным действие будучи требуется.Естественно, это не представляется возможным гарантировать, что сервер не
генерируют побочные эффекты в результате , выполняющего запрос GET; фактически, некоторые динамические ресурсы считают, что функция . Важным отличием является то, что пользователь не запрашивал побочные эффекты , поэтому не может нести ответственность за них.
GET имеет ограничение предельных данных на основе представляемого браузера:
спецификации для длины URL не диктует, как минимум или максимальную длину URL, но реализация варьируется в зависимости от браузера. В Windows: Opera поддерживает ~ 4050 символов, IE 4.0+ поддерживает ровно 2083 символа, Netscape 3 -> 4.78 поддерживает до 8192 символов, прежде чем вызывать ошибки при выключении, а Netscape 6 поддерживает ~ 2000, прежде чем вызывать ошибки при запуске.
Также может быть ограничение на запросы GET на стороне сервера. Например, у Apache установлен предел по умолчанию, равный [8190 байт] (https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline) –
Имейте в виду, что браузеры могут кэшировать GET-запросы, но, как правило, не кэшируют запросы POST.
По спецификациям HTTP GET безопасен и идемпотент, и POST не является ни тем, ни другим. Это означает, что запрос GET может повторяться несколько раз, не вызывая побочных эффектов.
Даже если вашему серверу все равно (и это маловероятно), между вашим клиентом и сервером могут быть промежуточные агенты, все из которых имеют это ожидание. Например, прокси-серверы кэшируют данные у вашего интернет-провайдера или других поставщиков для повышения производительности. Подобное ожидание справедливо и для ускорителей, например, для предпродажного плагина для вашего браузера.
Таким образом, запрос GET может быть кэширован (на основе определенных параметров), и если он терпит неудачу, его можно автоматически повторять без каких-либо последствий вредных эффектов. Итак, на самом деле ваш сервер должен стремиться выполнить этот контракт.
С другой стороны, POST не является безопасным, а не идемпотентным, и каждый агент знает, что он не кэширует результаты запроса POST, или автоматически запрашивает запрос POST. Так, например, транзакция с кредитными картами никогда бы никогда не была запросом GET (вы не хотите, чтобы счета дебетовали несколько раз из-за сетевых ошибок и т. Д.).
Это очень простой подход. Для получения дополнительной информации вы можете рассмотреть книгу «RESTful Web Services» Руби и Ричардсона (пресс-релиз O'Reilly).
Для быстрого взятия на тему REST, рассмотреть этот пост:
http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
Самое смешное, что большинство людей обсуждают достоинства PUT об POST. Проблема GET v POST и всегда была очень хорошо решена. Игнорируйте это на свой страх и риск.
Вы должны знать несколько тонких различий в безопасности. Смотрите мой вопрос
По существу, важно помнить, что GET войдет в историю браузера и будет передаваться через прокси в виде обычного текста, так что вы не хотите какой-либо конфиденциальной информации , как пароль в GET.
Очевидно, возможно, но стоит упомянуть.
Да, это имеет значение. GET и POST на самом деле очень разные.
Вы правы в том, что, как правило, GET предназначен для «получения» данных с сервера и отображения страницы, а POST - для «отправки» данных на сервер. Внутри ваши сценарии получают одни и те же данные, независимо от того, является ли это GET или POST, поэтому нет, сервер действительно не заботится.
Основное отличие - параметры GET указаны в URL-адресах, а POST - нет. Вот почему POST используется для регистрации и регистрационных форм - вы не хотите, чтобы ваш пароль был указан в URL-адресе. Аналогично, если вы просматриваете разные страницы или показываете конкретное представление некоторых данных, вы обычно хотите уникальный URL-адрес.
Не передавая свой пароль в URL-адресе, нет никакой безопасности, и никому не нужно проходить жизнь, сын. (Гринь). Если вы используете обычный текст (HTTP против HTTPS), ваш пароль будет виден, будет ли его POST или GET. – abelenky
Я никогда не говорил, что POST был более безопасным, я сказал, что вам не нужен ваш пароль в URL-адресе. Что произойдет, если пользователь разместит этот URL на форуме или что-то еще? – DisgruntledGoat
Технически, нет. Все GET - это публикация материала в первой строке HTTP-запроса, а POST-сообщения - в теле.
Однако, как «веб-инфраструктура» рассматривает разногласия, это создает мир различий. Мы могли бы написать целую книгу об этом. Тем не менее, я дам вам несколько «лучших практик»:
Используйте «POST», когда ваш запрос HTTP изменит что-то «конкретное» внутри веб-сервера. Т.е. вы редактируете страницу, создаете новую запись и так далее. POSTS с меньшей вероятностью будут кэшироваться или рассматриваться как нечто «повторяемое без побочных эффектов»
Используйте «GET», если хотите «посмотреть на объект». Теперь такой взгляд может изменить что-то «за кулисами» с точки зрения кеширования или записи, но он не должен ничего менять «существенным». То есть, я мог бы повторять мой GET снова и снова, и ничего плохого не произошло бы, кроме завышенных значений хита. GET должны быть легко заклассифицированы, поэтому пользователь может вернуться к тому же самому объекту позже.
Параметры GET (материал после «традиционно») следует рассматривать как «атрибуты представления» или «что посмотреть» и т. Д. Опять же, это ничего не должно изменить: используйте для этого POST.
И последнее слово, когда вы POST что-то (например, вы создаете новый комментарий), обработайте сообщение post 302, чтобы «перенаправить» пользователя на новый URL-адрес, который рассматривает этот объект , Т.е. POST обрабатывает информацию, затем перенаправляет браузер в инструкцию GET для просмотра нового состояния. Отображение информации в результате POST также может вызвать проблемы. Выполнение перенаправления часто используется и улучшает работу.
«Технически, нет». Это немного странно. Я имею в виду, что все, что мы программисты делаем, это те и нули в конце дня, так что «технически», нет никакой разницы между большей частью чего-либо! Авторитарной ссылкой здесь является спецификация HTTP (rfc 2616), которая делает техническое различие в разделе 9. – ars
ars: к сожалению, спецификация HTTP не упоминает, какие приложения (например, веб-сервер, cgi-скрипты, веб-приложение рамки) С этой информацией. Это невозможно узнать из спецификации HTTP. Таким образом, согласно спецификации, единственная разница заключается в том, как информация отправляется на HTTP-сервер. В зависимости от получателя (программа, которая получает данные) может быть разница ZERO между GET и POST, или мир различий. Итак, мой ответ: «Если вы сделаете это так, вы столкнетесь с меньшими проблемами, чем если бы вы сделали это любым другим способом». –
Чтение спецификации HTTP 1.1 может помочь вам http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html – RichardOD
Мне интересно ... Почему у этого вопроса есть 19 ответов, около 40 голосов ответы, и только один вопрос-ответ на вопрос (мой). Хороший вопрос! Неужели люди ленивы по поводу вопросов, связанных с голосованием? – abelenky
@abelenky - У меня не хватило голосов, чтобы дать вчера, вот +1 на сегодня –