Вопрос по asp.net, http – ПОЛУЧИТЬ против ПОЧТУ это действительно имеет значение?

14

Хорошо, я знаю разницу в целях. ПОЛУЧИТЬ, чтобы получить некоторые данные. Сделайте запрос и получите данные обратно. POST должен использоваться для операций CRUD, кроме чтения, я считаю. Но когда дело доходит до этого, действительно ли сервер заботится о том, получает ли он в итоге GET против POST?

Я должен задаться вопросом ... Почему у этого вопроса есть 19 ответов, около 40 голосов за ответы и только одно голосование "за" на вопрос (мой). Это хороший вопрос! Людям просто лень задавать вопросы? abelenky
@abelenky - у меня закончились голоса, чтобы дать вчера, здесь +1 на сегодня John Rasch
Чтение спецификации HTTP 1.1 может помочь вамw3.org/Protocols/rfc2616/rfc2616-sec9.html RichardOD
возможный дубликатIs either GET or POST more secure than the other? Roman Starkov

Ваш Ответ

19   ответов
1

йся странице? Еще одна вещь, о которой стоит подумать, это то, что некоторые браузеры / серверы некорректно ограничивают длину GET URI.

Edit: исправлено ограничение на длину символа - спасибо ars!

jbruce211: это ограничение, основанное на реализациях (например, браузерах или http-серверах). Это не предел, свойственный GET согласно спецификации HTTP. Из спецификации: «Протокол HTTP не устанавливает никаких априорных ограничений на длину URI. Серверы ДОЛЖНЫ иметь возможность обрабатывать URI любого ресурса, который они обслуживают, и ДОЛЖНЫ иметь возможность обрабатывать URI неограниченной длины, если они предоставляют формы на основе GET, которые могут генерировать такие URI. & Quot;w3.org/Protocols/rfc2616/rfc2616-sec3.html
-1

они не должны исключать ответ @ jbruce2112, а для загрузки файлов требуется POST.

12

если поисковая система сканирует страницу, так как они будут делать запросы GET, но не POST. Скажем, у вас есть ссылка на вашей странице:

http://www.example.com/items.aspx?id=5&mode=delete

Без какой-либо проверки авторизации, выполняемой перед удалением, возможно, что робот Google можетвойти и удалить элементы со своей страницы.

Отличная находка, Брайан, я искал именно эту статью для ссылки!
@Paco - и именно поэтому вы никогда не должны делать это таким образом :)
@Paco: Если ваш браузер загружает этот img, он будет использовать GET. Веб-сервер НЕ должен выполнять такие действия, как & quot; удалить & quot; на основе GET-запроса именно по этой причине. Веб-сервер несет ответственность за обеспечение того, чтобы серьезные действия происходили только через POST-запросы.
Даже с авторизацией злоумышленники могут отправить электронное письмо с тегом & lt; img src = & quot;example.com/items.aspx?id=5&mode=delete & Quot; & GT; кому-то, кто уже вошел в систему.
1

что более подходящий ответ, вы можете в значительной степени сделать то же самое с обоими. Однако это не столько вопрос предпочтения, сколько вопросcorrect usage, Я бы порекомендовал вам использовать GET и POST, как они былиintended использоваться.

0

библиотеки, такие как CGI.pm в perl, обрабатывают обе по умолчанию. Но существуют ситуации, когда вам более или менее необходимо использовать POST вместо GET, по крайней мере, для передачи данных на сервер. Большие объемы данных (где соответствующий URL-адрес GET станет слишком длинным), двоичные данные (чтобы избежать большого количества проблем с кодированием / декодированием), многокомпонентные файлы, неразборные заголовки (для непрерывных обновлений в стиле pre-AJAX ...) и аналогичные ,

0

что делает GET, - это публикует материал в первой строке HTTP-запроса, а POST - материал в теле.

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

Используйте & quot; POST & quot; когда ваш HTTP-запрос изменит что-то «конкретное» внутри веб-сервера. Т.е. вы редактируете страницу, делаете новую запись и так далее. Посты с меньшей вероятностью будут кэшироваться или рассматриваться как нечто, что «повторяется без побочных эффектов».

Используйте & quot; GET & quot; когда вы хотите «посмотреть на объект». Теперь такой взгляд может что-то изменить "за кулисами" с точки зрения кэширования или ведения записей, но это не должно ничего менять «существенным». То есть, я мог бы повторять свой GET снова и снова, и ничего плохого не случилось бы, за исключением завышенного количества попаданий. GET должны легко закладываться, чтобы пользователь мог вернуться к тому же объекту позже.

Параметры к GET (материал после?, Традиционно) должны рассматриваться как "атрибуты для представления" или "что посмотреть" и так далее. Опять же, это не должно ничего менять: для этого используйте POST.

И, наконец, последнее слово, когда вы что-то POST (например, создаете новый комментарий), обрабатываете для публикации 302 «перенаправить». пользователю новый URL, который просматривает этот объект. Т.е. POST обрабатывает информацию, а затем перенаправляет браузер в оператор GET для просмотра нового состояния. Отображение информации в результате POST также может вызвать проблемы. Перенаправление часто используется, и заставляет вещи работать лучше.

«Технически, нет». Это немного странно. Я имею в виду, что все, что мы, программисты, делаем единицами и нулями в конце дня, так что «технически», нет никакой разницы между многими вещами! Официальная ссылка здесь - это HTTP-спецификация (rfc 2616), которая делает техническое различие в разделе 9.
К сожалению, в спецификации HTTP не упоминается, что приложения (например, веб-сервер, сценарии cgi, платформы веб-приложений) ДЕЛАЮТ с этой информацией. Это не может быть получено из спецификации HTTP. Итак, согласно спецификации, единственное отличие состоит в том, как информация отправляется на HTTP-сервер. В зависимости от получателя (программы, которая получает данные), может быть нулевая разница между GET и POST или огромная разница. Итак, мой ответ: «Если вы сделаете это таким образом, у вас будет меньше проблем, чем если бы вы делали это любым другим способом».
4

вителя:

Спецификация для длины URL не определяет минимальную или максимальную длину URL, но реализация зависит от браузера. В Windows: Opera поддерживает ~ 4050 символов, IE 4.0+ поддерживает ровно 2083 символа, Netscape 3 - & gt; 4.78 поддерживает до 8192 символов до появления ошибок при завершении работы, а Netscape 6 поддерживает ~ 2000 до появления ошибок при запуске

1

некоторые браузеры ограничить длину запросов GET.

15

GET не должен иметь побочных эффектов, в то время как POST может иметь побочные эффекты.

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

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

ОтRFC 2616, 9.1.1:

9.1.1 Safe Methods

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.

Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

0

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

0

Вы правы в этом, как правило, GET предназначен для "получения" данные с сервера и отображение страницы, в то время как POST предназначен для "публикации" данные обратно на сервер. Внутренне, ваши сценарии получают те же данные, независимо от того, получены они или получены, поэтому нет, серверу это безразлично.

Основное отличие состоит в том, что параметры GET указываются в URL, а POST - нет. Вот почему POST используется для форм регистрации и входа - вам не нужен пароль в URL. Точно так же, если вы просматриваете разные страницы или отображаете определенный вид некоторых данных, вам обычно требуется уникальный URL-адрес.

Не передавать свой пароль в URL-адресе - это не безопасность и не способ жить, сынок. (Гринь). Если вы используете обычный текст (HTTP против HTTPS), ваш пароль виден как POST или GET.
Я никогда не говорил, что POST вообще более безопасен, я сказал, что вам не нужен пароль в URL. Что происходит, если пользователь публикует этот URL на форуме или чем-то еще?
0

какой запрос он получает. Он будет слепо выполнять любые запросы, поступающие по проводам.

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

0

который вы хотите получить, в зависимости от точного программного обеспечения на стороне сервера, веб-сервер (или балансировщик нагрузки перед ним) может иметь ограничение на размер запросов GET для предотвращения атак типа «отказ в обслуживании» ...

1

ой вопрос

GET versus POST in terms of security?

По существу, важно помнить, что GET войдет в историю браузера и будет передаваться через прокси в виде простого текста, поэтому вам не нужна любая конфиденциальная информация, например пароль в GET.

Очевидное может быть, но стоит упомянуть.

2

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

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

Таким образом, GET-запрос может быть кэширован (на основе определенных параметров), а в случае сбоя он может автоматически повторяться без каких-либо ожиданий вредных последствий. Итак, действительно ваш сервер должен стремиться выполнить этот контракт.

С другой стороны, POST не является безопасным, не идемпотентным, и каждый агент знает, что не нужно кэшировать результаты запроса POST или повторять запрос POST автоматически. Так, например, транзакция по кредитной карте никогда не будет GET-запросом (вы не хотите, чтобы аккаунты были списаны несколько раз из-за сетевых ошибок и т. Д.).

Это очень простой взгляд на это. Для получения дополнительной информации вы могли бы рассмотреть & quot; RESTful Web Services & quot; книга Руби и Ричардсона (O 'Reilly Press).

Для быстрого ознакомления с темой REST рассмотрите этот пост:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Самое смешное, что большинство людей обсуждают достоинства PUT v POST. Проблема GET v POST была и всегда была очень хорошо решена. Игнорировать это на свой страх и риск.

2

& quot; Используйт GET, сли: взаимодйстви больш похож на вопрос (т.. это бзопасная опрация, такая как запрос, опрация чтния или поиск). & quot;

& quot; Использовать POST, сли: взаимодйстви больш похож на порядок, либо взаимодйстви измнят состояни рсурса таким образом, который пользоватль будт воспринимать (напримр, подписка на услугу), либо пользоватль будт нсти отвтствнность за рзультаты взаимодйствия. & quot;

источник

9

о), вам будет важно, если вы скажете ему это. Если вы обрабатываете данные POST и GET одинаково, то нет, это не так.

Тем не менее, браузер определенно заботится. При обновлении или переходе на страницу, полученную вами в ответ на POST, появляется сообщение "Вы уверены, что хотите снова отправить данные"? подскажите, например.

Конечно. И это в значительной степени моя точка зрения. С точки зрения браузера, имеет значение, отправляете ли вы данные через POST или GET, и поэтому они должны обрабатываться сервером по-разному. Я бы не назвал это «обходным путем» хотя, поскольку это подразумевает, что поведение браузера является ошибкой. Это работает по совершенно веской причине, и «обходной путь» это совершенно логичный способ справиться с этим.
Однако это можно обойти, если ваш код, обрабатывающий запрос POST, никогда ничего не отображает, а вместо этого перенаправляет на страницу, которая это делает. Увидетьen.wikipedia.org/wiki/Post/Redirect/Get
Что еще более важно, вы можете использовать шаблон Post / Redirect / Get, чтобы предотвратить случайный повтор действий людей.
2

вы рискуете получить плохие вещи, если какой-либо веб-сканер пересекает ваш сайт. Когда вики впервые стали популярными, были ужасные истории об удалении целых сайтов, потому что & quot; удалить страницу & quot; функция была реализована в виде запроса GET, что привело к катастрофическим результатам, когда робот Google постучал ...

0

что браузеры могут кэшировать запросы GET, но, как правило, не кэшируют запросы POST.

Похожие вопросы