GET vs. POST

HTTP POST изисква предоставяне на допълнителни данни от клиента (браузъра) на сървъра в тялото на съобщението. За разлика, GET заявките включват всички необходими данни в URL адреса. Формите в HTML могат да използват всеки метод, като посочат метод = "POST" или метод = "да" (по подразбиране) в елемент. Определеният метод определя как данните на формуляра се предават на сървъра. Когато методът е GET, всички данни от формуляра се кодират в URL адреса, добавен към действие URL като параметри на низ за заявка С POST данните на формуляра се появяват в тялото на съобщението на HTTP заявката.

Сравнителна диаграма

GET спрямо POST диаграма за сравнение

	GET	POST

история	Параметрите остават в историята на браузъра, защото са част от URL адреса	Параметрите не се записват в историята на браузъра.
са запазени отметки	Може да бъде отметка.	Не може да бъде отметка.
BACK / повторно подаване на поведение	GET заявките се изпълняват отново, но може да не бъдат повторно изпратени на сървъра, ако HTML се съхранява в кеша на браузъра.	Обикновено браузърът предупреждава потребителя, че данните ще трябва да бъдат изпратени отново.
Тип кодиране (атрибут enctype)	прилагане / х-WWW-форма-urlencoded	многочасти / формуляр-данни или приложение / x-www-form-urlencoded Използвайте многочастично кодиране за двоични данни.
Параметри	може да изпраща, но данните от параметрите са ограничени до това, което можем да впишем в реда за заявка (URL). Най-безопасно да се използват по-малко от 2K параметри, някои сървъри обработват до 64K	Може да изпраща на сървъра параметри, включително качване на файлове.
Hacked	По-лесно за хакване за скриптове деца	По-трудно за хакване
Ограничения за типа данни на формуляра	Да, разрешени са само ASCII символи.	Без ограничения. Бинарните данни също са позволени.
Сигурност	GET е по-малко сигурен в сравнение с POST, защото изпратените данни са част от URL адреса. Така че се запазва в историята на браузъра и в дневниците на сървъра в незабележим текст.	POST е малко по-безопасен от GET, защото параметрите не се съхраняват в историята на браузъра или в дневниците на уеб сървъра.
Ограничения в дължината на формуляра	Да, тъй като данните на формуляра са в URL адреса, а дължината на URL адреса е ограничена. Ограничението за дължина на сигурния URL адрес често е 2048 знака, но варира в зависимост от браузъра и уеб сървъра.	Без ограничения
ползваемост	GET методът не трябва да се използва при изпращане на пароли или друга чувствителна информация.	Метод POST, използван при изпращане на пароли или друга чувствителна информация.
видимост	Методът GET е видим за всички (той ще бъде показан в адресната лента на браузъра) и има ограничения за количеството информация, която трябва да изпратите.	Променливите на метода POST не се показват в URL адреса.
Кеширана	Може да се кешира	Не е кеширано

Съдържание: GET срещу POST

1 Разлики във формуляра за подаване на формуляри
- 1.1 плюсове и минуси
2 Разлики в обработката от страна на сървъра
3 Препоръчителна употреба
4 Какво ще кажете за HTTPS?
5 Позовавания

Разлики във формуляра за подаване на формуляри

Фундаменталната разлика между МЕТОД = "GET" и МЕТОД = "POST" е, че те съответстват различни HTTP заявки, както е дефинирано в спецификациите на HTTP. Процесът на подаване и за двата метода започва по един и същ начин - набор от данни на формуляр се конструира от браузъра и след това се кодира по начин, определен от enctype атрибут. За МЕТОД = "POST на enctype атрибут може да бъде съставното / формата данни или прилагане / х-WWW-форма-urlencoded, като има предвид, че за МЕТОД = "GET", само прилагане / х-WWW-форма-urlencoded е позволено. Този набор от данни след това се предава на сървъра.

За изпращане на формуляр с METHOD = "GET", браузърът конструира URL, като приема стойността на действие атрибут, добавяне a ? към него, след което добавете набора от данни на формуляра (кодиран с помощта на типа съдържание / x-www-form-urlencoded). След това браузърът обработва този URL адрес, сякаш следва линк (или сякаш потребителят е въвел URL адреса директно). Браузърът разделя URL адреса на части и разпознава хост, след което изпраща на този хост GET заявка с останалата част от URL като аргумент. Сървърът го взема от там. Обърнете внимание, че този процес означава, че данните от формулярите са ограничени до ASCII кодове. Трябва да се обърне специално внимание на кодирането и декодирането на други типове символи при преминаването им през URL адреса във формат ASCII.

Подаването на формуляр с METHOD = "POST" води до изпращане на заявка POST, използвайки стойността на действие атрибут и съобщение, създадено според типа съдържание, посочен от enctype атрибут.

Предимства и недостатъци

Тъй като данните от формулярите се изпращат като част от URL адреса, когато GET се използва --

Данните от формуляра са ограничени до ASCII кодове. Трябва да се обърне специално внимание на кодирането и декодирането на други типове символи при преминаването им през URL адреса във формат ASCII. От друга страна, всички бинарни данни, изображения и други файлове могат да бъдат изпращани чрез МЕТОД = "POST"
Всички попълнени данни на формуляра се виждат в URL адреса. Освен това, той се съхранява и в историята / регистрационните файлове на браузъра на потребителя. Тези проблеми правят GET по-малко сигурни.
Едно от предимствата на данните за формуляри, които се изпращат като част от URL адреса, е, че можете да маркирате URL адресите и да ги използвате директно и напълно да заобиколите процеса на попълване на формуляра.
Има ограничение за това колко данни на формуляра могат да се изпращат, тъй като дължините на URL адресите са ограничени.
Децата на скриптове могат по-лесно да разкрият уязвимостите в системата, за да го хакнат. Например Citibank бе хакнат чрез промяна на номера на сметки в URL низа.^[1] Разбира се, опитни хакери или уеб разработчици могат да изложат такива уязвимости, дори ако се използва POST; просто е малко по-трудно. По принцип сървърът трябва да е подозрителен към всякакви данни, изпратени от клиента и да се предпазва от Несигурни директни препратки към обекти.

Разлики в обработката от страна на сървъра

По принцип обработката на подадени данни от формуляр зависи от това дали се изпраща с МЕТОД = "GET" или МЕТОД = "POST". Тъй като данните са кодирани по различни начини, са необходими различни механизми за декодиране. По този начин, като цяло, промяната на METHOD може да наложи промяна в скрипта, който обработва подаването. Например, когато използвате интерфейса CGI, скриптът получава данните в променлива среда (QUERYSTRING), когато GET се използва. Но когато POST се използва, данните от формулярите се предават в стандартния входен поток (стандартния вход) и броят на байтове, които ще бъдат прочетени, се определя от заглавката на Content-length.

Препоръчителна употреба

GET се препоръчва, когато изпращате формуляри с „idempotent“ - такива, които не „променят значително състоянието на света“. С други думи, формуляри, които включват само заявки към база данни. Друга перспектива е, че няколко еднопосочни заявки ще имат същия ефект като една заявка. Ако са включени актуализации на базата данни или други действия, като задействане на имейли, се препоръчва използването на POST.

От блога за разработчици на Dropbox:

браузърът не знае точно какво прави определен HTML формат, но ако формулярът е подаден чрез HTTP GET, браузърът знае, че е безопасно автоматично да опита отново, ако има мрежова грешка. За форми, които използват HTTP POST, може да не е безопасно да се опита отново, така че браузърът първо да поиска от потребителя потвърждение.

Заявка „GET“ често е кешираща, докато заявка „POST“ трудно може да бъде. За запитващите системи това може да има значително въздействие върху ефективността, особено ако низовете на заявките са прости, тъй като кешовете могат да обслужват най-честите заявки.

В определени случаи, използвайки POST се препоръчва дори за idempotent заявки:

Ако данните от формуляра ще съдържат символи, които не са ASCII (като например ударени знаци), тогава МЕТОД = "GET" е неприложимо по принцип, въпреки че може да работи на практика (главно за ISO латиница 1 знак).
Ако наборът от формуляри е голям - да речем, стотици герои - тогава МЕТОД = "GET" може да причини практически проблеми с реализациите, които не могат да се справят с толкова дълги URL адреси.
Може би искате да избегнете МЕТОД = "GET" за да стане по-малко видимо за потребителите как работи формулярът, особено за да направят „скритите“ полета (INPUT TYPE = „HIDDEN“) по-скрити, като не се показват в URL адреса. Но дори и да използвате скрити полета с МЕТОД = "POST", те все още ще се показват в изходния код на HTML.

Ами HTTPS?

Актуализирано на 15 май 2015 г .: По-конкретно, когато използвате HTTPS (HTTP през TLS / SSL), предлага ли POST по-голяма сигурност от GET?

Това е интересен въпрос. Кажете, че отправяте GET заявка към уеб страница:

 ВЗЕМЕТЕ https://www.example.com/login.php?user=mickey&passwd=mini

Ако приемем, че вашата интернет връзка се следи, каква информация за тази заявка ще бъде на разположение на снайпериста? Ако вместо това се използва POST и данните на потребителя и passwd са включени в променливите на POST, това ще бъде ли по-сигурно в случай на HTTPS връзки?

Отговорът е не. Ако направите такава GET заявка, нападателят ще следи само следната информация, която следи вашия уеб трафик:

Фактът, че сте направили HTTPS връзка
Името на хоста - www.example.com
Общата дължина на заявката
Дължината на отговора

Частта от пътя на URL адреса - т.е. реално заявената страница, както и параметрите на низа на заявката - са защитени (криптирани), докато са „над проводника“, т.е. по време на транзит на път към целевия сървър. Ситуацията е точно такава за POST заявките.

Разбира се, уеб сървърите са склонни да записват целия URL адрес с обикновен текст в своите дневници за достъп; така че изпращането на чувствителна информация през GET не е добра идея. Това се прилага независимо от това дали се използва HTTP или HTTPS.

Препратки

уикипедия: POST (HTTP)
Методи за заявка на HTTP
HTTP Post - W3.org
HTTP Get - W3.org
HTTPS крие ли URL адресите, до които се осъществява достъп? - Обмен на стекове

технология