ГЕТ вс. ПОСТ

ХТТП ПОШТА захтева достављање додатних података од клијента (претраживача) на сервер у телу поруке. У супротности, ДОБИТИ захтеви укључују све потребне податке у УРЛ-у. Обрасци у ХТМЛ-у могу користити било коју методу специфицирањем метход = "ПОСТ" или метход = "ГЕТ" (подразумевано) у елемент. Наведена метода одређује како се подаци обрасца достављају серверу. Када је метода ГЕТ, сви подаци обрасца се кодирају у УРЛ, додају у поступак УРЛ као параметри низа упита Помоћу ПОСТ-а подаци обрасца се појављују у тијелу поруке ХТТП захтјева.

Упоредни графикон

ГЕТ у односу на ПОСТ упоредни графикон

	ДОБИТИ	ПОШТА
Историја	Параметри остају у историји прегледача јер су део УРЛ адресе	Параметри се не чувају у историји прегледача.
Означено	Може да се обележи.	Не може се обележити.
БАЦК / поново пошаљи понашање	ГЕТ захтеви се поново извршавају, али се не могу поново послати серверу ако је ХТМЛ сачуван у кешу претраживача.	Прегледач обично упозорава корисника да ће податке требати поново доставити.
Врста кодирања (атрибут енцтипе)	апликација / к-ввв-форм-урленцодед	мултипарт / дата-дата или апликација / к-ввв-форм-урленцодед Користите вишестрано кодирање за бинарне податке.
Параметри	може слати, али подаци о параметрима ограничени су на оно што можемо убацити у линију захтева (УРЛ). Најсигурније за коришћење мање од 2К параметара, неки сервери обрађују до 64К	Могу да шаљу параметре, укључујући уплоад датотека, на сервер.
Хакиран	Лакше за хакирање за скрипте за децу	Теже је хаковати
Ограничења у врсти података обрасца	Да, дозвољени су само АСЦИИ знакови.	Нема ограничења. Бинарни подаци су такође дозвољени.
Сигурност	ГЕТ је мање сигуран у односу на ПОСТ јер су послани подаци део УРЛ-а. Тако се чува у историји прегледача и записима сервера у отвореном тексту.	ПОСТ је мало сигурнији од ГЕТ-а, јер се параметри не чувају у историји прегледача или у записима веб сервера.
Ограничења у дужини података обрасца	Да, пошто су подаци обрасца у УРЛ-у, а дужина УРЛ-а је ограничена. Сигурна граница дужине УРЛ адреса је често 2048 знакова, али варира од претраживача и веб сервера.	Нема ограничења
Употребљивост	ГЕТ метода се не сме користити приликом слања лозинки или других осетљивих информација.	ПОСТ метода која се користи приликом слања лозинки или других осетљивих информација.
Видљивост	ГЕТ метода је видљива свима (биће приказана у адресној траци прегледача) и има ограничења у количини информација које треба послати.	Променљиве методе ПОСТ се не приказују у УРЛ-у.
Предмеморирано	Може се кеширати	Не кеширано

Садржај: ГЕТ вс ПОСТ

• 1 Разлике у подношењу обрасца
  • 1.1 За и против
• 2 разлике у обради на страни сервера
• 3 Препоручена употреба
• 4 Шта је са ХТТПС-ом?
• 5 Референце

Разлике у подношењу обрасца

Темељна разлика између МЕТХОД = "ГЕТ" и МЕТХОД = "ПОСТ" је да они одговарају различити ХТТП захтеви, како је дефинисано у ХТТП спецификацијама. Процес подношења обе методе започиње на исти начин - прегледач формира скуп података података обрасца, а затим их кодира на начин који је специфициран од стране енцтипе атрибут. За МЕТХОД = "ПОСТ тхе тхе енцтипе атрибут може бити мултипарт / форм-дата или апликација / к-ввв-форм-урленцодед, док за МЕТХОД = "ГЕТ", само апликација / к-ввв-форм-урленцодед је дозвољено. Овај скуп података обрасца затим се преноси на сервер.

За слање обрасца са МЕТХОД = "ГЕТ", прегледач конструише УРЛ узимајући вредност од поступак атрибут, додајући а ? на њега, затим додавањем скупа података обрасца (кодираног помоћу врсте садржаја / к-ввв-форм-урленцодед). Онда прегледач обрађује овај УРЛ као да следи везу (или као да је корисник директно уписао УРЛ). Прегледач подели УРЛ на делове и препозна хост, а затим њему пошаље ГЕТ захтев са остатком УРЛ-а као аргумент. Сервер га узима одатле. Имајте на уму да овај поступак значи да су подаци обрасца ограничени на АСЦИИ кодове. Посебну пажњу треба посветити кодирању и декодирању осталих врста знакова приликом њиховог проласка кроз УРЛ у АСЦИИ формату.

Подношење обрасца са МЕТХОД = "ПОСТ" узрокује слање ПОСТ захтева користећи вредност поступак атрибут и порука креирана у складу са типом садржаја који је одредио енцтипе атрибут.

За и против

Будући да се подаци обрасца шаљу као део УРЛ адресе када ДОБИТИ се користи --

• Подаци обрасца ограничени су на АСЦИИ кодове. Посебну пажњу треба посветити кодирању и декодирању осталих врста знакова приликом њиховог проласка кроз УРЛ у АСЦИИ формату. Са друге стране, бинарни подаци, слике и друге датотеке могу се доставити путем МЕТХОД = "ПОСТ"
• Сви попуњени подаци обрасца видљиви су у УРЛ-у. Штавише, такође се чува у корисничкој историји / записима претраживача за веб претраживач. Ова питања чине ДОБИТИ мање безбедан.
• Међутим, једна од предности података образаца који се шаљу као део УРЛ-а је та што можете да обележите УРЛ адресе и директно их употребите и потпуно заобиђете поступак попуњавања формулара.
• Постоји ограничење у томе колико података података обрасца може да се пошаље, јер су дужине УРЛ-ова ограничене.
• Клинци на скриптама могу лакше изложити рањивости у систему да их хакују. На пример, Цитибанк је хакиран променом бројева рачуна у УРЛ-у.^[1] Наравно, искусни хакери или веб програмери могу изложити такве рањивости чак и ако се користи ПОСТ; то је само мало теже. Генерално, сервер мора бити сумњив према било каквим подацима које му је послао клијент и заштитити се од несигурних директних референци објекта.

Разлике у обради на страни сервера

У принципу, обрада посланих података обрасца зависи од тога да ли се шаље са њима МЕТХОД = "ГЕТ" или МЕТХОД = "ПОСТ". Будући да се подаци кодирају на различите начине, потребни су различити механизми декодирања. Стога, генерално говорећи, промена МЕТОДА може захтевати промену скрипте која обрађује пријаву. На пример, када користите ЦГИ интерфејс, скрипта прима податке у променљивој околини (КУЕРИСТРИНГ) када ДОБИТИ се користи. Али када ПОШТА користи се, образац се преноси у стандардном улазном току (стдин), а број бајтова за читање даје се у заглављу дужине садржаја.

Препоручена употреба

ГЕТ се препоручује приликом слања „идемпотентних“ образаца - оних који не „значајно мењају стање у свету“. Другим речима, обрасци који укључују само упите у базе података. Друга перспектива је да ће неколико идемпотентних упита имати исти ефекат као један упит. Ако су укључене надоградње базе података или друге радње, попут покретања е-поште, препоручује се употреба ПОСТ-а.

Са блога програмера Дропбок:

прегледач не зна тачно шта одређени ХТМЛ образац ради, али ако се образац предаје путем ХТТП ГЕТ-а, прегледач зна да је сигурно аутоматски поново покушати ако постоји мрежна грешка. За обрасце који користе ХТТП ПОСТ можда није сигурно покушати поново, тако да прегледач прво тражи од корисника потврду.

Захтев „ГЕТ“ је често кеширан, док захтев „ПОСТ“ тешко може бити. За системе упита ово може имати значајан утицај на ефикасност, посебно ако су редови упита једноставни, јер предмемори могу послужити најчешће упите.

У одређеним случајевима помоћу ПОШТА препоручује се чак и за идемпотентне упите:

• Ако подаци обрасца садрже знакове који нису АСЦИИ (попут знакова с нагласком), затим МЕТХОД = "ГЕТ" је у принципу непримењиво, иако може радити у пракси (углавном за ИСО латиничне 1 знакове).
• Ако је скуп података обрасца велик - рецимо, стотине ликова - тада МЕТХОД = "ГЕТ" може да створи практичне проблеме са имплементацијама које не могу да подносе тако дугачке УРЛ адресе.
• Можда желите да избегнете МЕТХОД = "ГЕТ" како би корисницима било мање видљиво како образац функционише, посебно у циљу скривања "скривених" поља (ИНПУТ ТИПЕ = "ХИДДЕН") не појављивањем у УРЛ-у. Али чак и ако користите скривена поља са МЕТХОД = "ПОСТ", они ће се и даље појавити у изворном ХТМЛ коду.

Шта је са ХТТПС-ом?

Ажурирано 15. маја 2015. године: Да ли ПОСТ нуди већу сигурност од ГЕТ-а, када се користи ХТТПС (ХТТП преко ТЛС / ССЛ)?

Ово је занимљиво питање. Реците да шаљете ГЕТ захтев веб страници:

 ГЕТ хттпс://ввв.екампле.цом/логин.пхп?усер=мицкеи&пассвд=мини 

Под претпоставком да се интернетска веза надгледа, које ће информације о овом захтеву бити доступне снооперу? Ако се уместо тога користи ПОСТ, а подаци корисника и пассвд укључе се у ПОСТ променљиве, да ли ће то бити сигурније у случају ХТТПС веза?

Одговор је не. Ако поставите такав ГЕТ захтев, нападачу који прати ваш веб саобраћај биће познате следеће информације:

1. Чињеница да сте успоставили ХТТПС везу
2. Име домаћина - ввв.екампле.цом
3. Укупна дужина захтева
4. Дужина одговора

Дио путање УРЛ-а - тј. Стварна тражена страница, као и параметри низа упита - заштићени су (шифрирани) док су „преко жице“, тј. У транзиту, на путу до одредишног сервера. Ситуација је потпуно иста и за ПОСТ захтеве.

Наравно, веб сервери имају тенденцију да цео УРЛ бележе обичним текстом у својим записима приступа; па слање осетљивих информација преко ГЕТ-а није добра идеја. Ово се односи без обзира да ли се користи ХТТП или ХТТПС.

Референце

• википедиа: ПОСТ (ХТТП)
• Методе захтева ХТТП-а
• ХТТП пошта - В3.орг
• ХТТП Гет - В3.орг
• Да ли ХТТПС скрива УРЛ адресе којима се приступа? - Стацк Екцханге