Есть ли какое-либо серьезное основание, почему я должен заботиться о том, если параметры были переданы через, ДОБИРАЮТСЯ или POST?

] В некоторых случаях принятие GET, а не сообщения может сделать вас более подверженным CSRF-атаке. Однако, это не сложное и быстрое правило, и вы должны предпринять шаги для предотвращения CSRF даже при принятии POST.[

]GET-запросы могут быть занесены в закладки, связаны с ними и сохранены в истории браузера. Это может быть хорошо или плохо; например, ваши пользователи не хотели бы, чтобы другие люди видели, что они вистили example.com/?password=jigglypuff, или чтобы кто-то обманул их, перейдя по ссылке example.com/?changepasswordto=irh4x0r[

] Из []W3[]:[

] [

]9.1.1 Безопасные методы [

] [

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

] [

] В частности, конвенция была установили, что GET и HEAD методы НЕ ДОЛЖНЫ важность принятия мер другого характера чем извлечение. Эти методы должны считаются "безопасными". Это позволяет пользователю агентов для представления других методов, таких как ПОСТ, ПУТ и ДЕЛЕТ, в особым образом, чтобы пользователь был сделан осознавая тот факт, что возможно Просим принять небезопасные меры. [

] [

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

] [

]Методы могут также обладать свойством "идолопоклонство" в этом (не считая ошибки или истечения срока действия) побочные эффекты N > 0 идентичны запросы такие же, как и для одного просьба. Методы GET, HEAD, PUT и Делит разделяет эту собственность. Также, методы ВАРИАНТЫ и ТРЕЙС ШОУ Не имеют побочных эффектов, как и врождённо идиотский. [

] [

] Однако не исключено, что последовательность нескольких запросов не является идиотский, даже если все методы выполняются в указанной последовательности идиотка. (Последовательность - идиотская если однократное исполнение всего последовательность всегда дает результат, который не меняется в результате повторного исполнения все или часть этой последовательности).) Для пример, последовательность не является бессильной если его результат зависит от значения, которое позже модифицируется в том же последовательность. [

] [

] Последовательность, которая никогда не имеет побочных эффектов. является идолопоклонным, по определению (при условии, что что никакие параллельные операции выполняемый на одном и том же наборе ресурсы).[

] [

]Таким образом, в основном GET предназначена для идолопоклонства (если вы повторно отправите форму, то в итоге получите тот же результат, что и один раз - в результате вы не получите от Amazon дважды доставленные вами заказы, например.) POST призван быть более либеральным в том, как он ведет себя.[

Как многие утверждали, это зависит от приложения, которое вы создаете. Одна вещь, с которой я столкнулся при работе нескольких веб-приложений, - это то, что если вы используете GET, существует ограничение на размер (я считаю, 255 байтов). В зависимости от того, что вы делаете, это может не быть проблемой, но в обстоятельствах, когда у вас есть большие объемы текста или параметров, передаваемых обратно на сервер, вы можете достичь этого предела, и это сведет вас с ума, пытаясь выяснить, что произошло!

Я считаю, что популярный фреймворк Ruby on Rails объединяет их в переменную params (технически метод ...), но также позволяет вам получить доступ к исходным параметрам GET или POST другими способами.

В моем коде я комбинирую их оба, но пока не столкнулся с какими-либо проблемами.

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

Или, говоря таким образом: Я использую POST для администрирования и GET для навигации.

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

64-битные углеродные API на Mac OS X: я не сгорел лично, Но у меня есть друг, работающий на большую программную компанию, которая провела год, конвертируя почти весь их код, чтобы использовать 64-битные углеродные API только для того, чтобы выяснить в WWDC, что эти API больше не будут доступны.

POST и Получить Запрос имеет разные семантические. Краткое описание доступно на википедии . В основном A запрос

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

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

Пример того, что может произойти, если GOW запрос не просто возвращает ресурс с вышеупомянутыми ограничениями: Умышленный разрушение .

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

yourpage.aspx? Action = Create & Parame = abcde

Если я случится в Bookmark это сделать (это может быть случайно, потому что он отображает другую страницу, которую я хочу закладки) Каждый раз, когда я открываю свою закладку, я пытаюсь создать новый предмет.

Это особенно беспокойство, когда поисковая система вступает в игру - если вы объединяете это с плохой аутентификацией, то в данный момент, когда Google начинает индексирование всех этих «? Action = Удалить» ссылки, забавное.

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

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

В идеале *, POST имеет (или может иметь, быть педантичными) побочными эффектами и Get не. Таким образом, третья сторона может следовать получать ссылки без страха, удаляя вещи. Или все, что проходит для модификации в системе.

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

Я бы не слился бы два, просто потому, что вы теряете эти различия.

_{* Хорошо, много людей винтить это, чтобы вы не могли положиться на это поведение; Но зачем вклад в проблему?}

Некоторые звонки действительно должны быть пост-только или предоставлять другие средства (например, простой подтверждающий вопрос), чтобы он действительно пользователя , который запросил некоторые действия. При разрешении можно изменить вещи, можно уязвимо к подделке запроса на перекрестную площадку (CSRF). Итак:

Для обеспечения безопасного способа использовать разработчики, вы могут одновременно обеспечить разработчики, чтобы явно определить, ожидают ли они получить или пост. Следовательно, вы можете не Хотите объединить параметры? Когда не слияние, получается, вероятно, не удастся, если сценарий относится к размещению параметров.