GET vs. POST

HTTP POST zahteva posredovanje dodatnih podatkov odjemalca (brskalnika) strežniku v telesu sporočil. V nasprotju, DOBI zahteve vključujejo vse zahtevane podatke v URL. Obrazci v HTML lahko uporabite katero koli metodo tako, da določite metoda = "POST" ali metoda = "DOBI" (privzeto) v element. Navedena metoda določa, kako se podatki obrazca oddajo strežniku. Ko je metoda GET, so vsi podatki obrazca kodirani v URL, priloženi k ukrepanje URL kot parametri niza poizvedbe. Z POST se podatki obrazca prikažejo v telesu sporočila zahteve HTTP.

Primerjalna tabela

GET v primerjavi s POST primerjalno tabelo

	DOBI	POST

Zgodovina	Parametri ostanejo v zgodovini brskalnika, ker so del URL-ja	Parametri niso shranjeni v zgodovini brskalnika.
Zaznamek	Lahko je zaznamek.	Ni mogoče zaznamek.
Gumb NAZAJ / ponazorite znova	Zahteve GET se ponovno izvršijo, vendar jih morda ne bodo ponovno poslali strežniku, če je HTML shranjen v predpomnilniku brskalnika.	Brskalnik običajno opozori uporabnika, da bo treba podatke ponovno predložiti.
Vrsta kodiranja (atribut enctype)	prijava / x-www-form-urlencoded	multipart / form-data ali aplikacija / x-www-form-urlencoded Uporabite večdelno kodiranje za binarne podatke.
Parametri	lahko pošljemo, vendar so podatki parametrov omejeni na tisto, kar lahko vstavimo v zahtevno vrstico (URL). Najvarneje je uporabljati manj kot 2K parametrov, nekateri strežniki pa do 64K	Na strežnik lahko pošlje parametre, vključno z nalaganjem datotek.
Hakirani	Lažje kramp za skripte otroške	Težje za hec
Omejitve glede vrste podatkov obrazca	Da, dovoljeni so samo ASCII znaki.	Brez omejitev. Dovoljeni so tudi binarni podatki.
Varnost	GET je manj varen v primerjavi s POST, ker so poslani podatki del URL-ja. Torej je shranjena v zgodovini brskalnika in dnevnikih strežnikov v odprtem besedilu.	POST je nekoliko varnejši od GET, ker parametri niso shranjeni v zgodovini brskalnika ali v dnevnikih spletnega strežnika.
Omejitve glede dolžine podatkov obrazca	Da, saj so podatki obrazca v URL-ju in je dolžina URL-ja omejena. Omejitev dolžine varne URL-je je pogosto 2048 znakov, vendar se razlikuje glede na brskalnik in spletni strežnik.	Brez omejitev
Uporabnost	GET metode se ne sme uporabljati pri pošiljanju gesel ali drugih občutljivih informacij.	Metoda POST, ki se uporablja pri pošiljanju gesel ali drugih občutljivih informacij.
Vidnost	Metoda GET je vidna vsem (prikazana bo v naslovni vrstici brskalnika) in ima omejitve glede količine informacij za pošiljanje.	Spremenljivke metode POST niso prikazane v URL-ju.
Predpomnjeno	Lahko se predpomni	Ni predpomnjeno

Vsebina: GET vs POST

1 Razlike v oddaji obrazca
- 1.1 Prednosti in slabosti
2 razlike pri obdelavi na strani strežnika
3 Priporočena uporaba
4 Kaj pa HTTPS?
5 Reference

Razlike v oddaji obrazca

Temeljna razlika med METHOD = "DOBI" in METHOD = "POST" je, da ustrezajo različne zahteve HTTP, kot je opredeljeno v specifikacijah HTTP. Postopek oddaje za obe metodi se začne na enak način - brskalnik oblikuje niz podatkov o obrazcu in ga nato kodira na način, ki ga določi entipe atribut. Za METHOD = "POST the entipe atribut je lahko podatki o več delih / oblikah ali prijava / x-www-form-urlencoded, ker za METHOD = "DOBI", samo prijava / x-www-form-urlencoded je dovoljeno. Ta niz podatkov obrazca se nato pošlje strežniku.

Za oddajo obrazca z METHOD = "GET" brskalnik ustvari URL tako, da sprejme vrednost ukrepanje atribut, dodatek a ? vanj, nato pa doda dodatek podatkov obrazca (kodiran z uporabo vsebine type / x-www-form-urlencoded type). Brskalnik nato obdela ta URL, kot da sledi povezavi (ali kot da bi uporabnik neposredno vtipkal URL). Brskalnik razdeli URL na dele in prepozna gostitelja, nato pa temu gostitelju pošlje zahtevo GET s preostankom URL-ja kot argument. Strežnik ga odnese od tam. Upoštevajte, da ta postopek pomeni, da so podatki obrazca omejeni na kode ASCII. Posebno previdno je treba kodirati in dekodirati druge vrste znakov, ko jih prenašate skozi URL v obliki ASCII.

Predložitev obrazca z METHOD = "POST" povzroči pošiljanje zahteve POST z uporabo vrednosti ukrepanje atribut in sporočilo, ustvarjeno glede na vrsto vsebine, ki jo določi entipe atribut.

Prednosti in slabosti

Ker se podatki obrazca pošljejo kot del URL-ja ob DOBI se uporablja --

Podatki obrazca so omejeni na ASCII kode. Posebno previdno je treba kodirati in dekodirati druge vrste znakov, ko jih prenašate skozi URL v obliki ASCII. Po drugi strani je mogoče vse binarne podatke, slike in druge datoteke oddati prek METHOD = "POST"
Vsi izpolnjeni podatki obrazca so vidni v URL-ju. Poleg tega je shranjena tudi v zgodovini / dnevnikih brskalnika za uporabnike. Te težave povzročajo DOBI manj varna.
Vendar je ena prednost podatkov obrazca, ki se pošiljajo kot del URL-ja, ta, da lahko URL-je zaznamujete in jih neposredno uporabite ter popolnoma zaobidete postopek izpolnjevanja obrazcev..
Obstaja omejitev, koliko podatkov obrazca lahko pošljete, ker je dolžina URL-ja omejena.
Otroci s skripta lahko lažje izpostavijo ranljivosti v sistemu, da jih ta vlomi. Na primer, Citibank je bil prekinjen s spreminjanjem številk računov v nizu URL.^[1] Seveda lahko izkušeni hekerji ali spletni razvijalci izpostavijo takšne ranljivosti, tudi če se uporablja POST; le malo težje je. Na splošno mora biti strežnik sumljiv na kakršne koli podatke, ki jih je poslala stranka, in jih varuje pred Nevarnimi referencami neposrednih objektov.

Razlike v obdelavi na strani strežnika

Načeloma je obdelava poslanih podatkov obrazca odvisna od tega, ali so poslani METHOD = "DOBI" ali METHOD = "POST". Ker so podatki kodirani na različne načine, so potrebni različni mehanizmi dekodiranja. Tako lahko na splošno sprememba METODA zahteva spremembo skripte, ki obdela oddajo. Na primer, ko uporabljate vmesnik CGI, skript prejme podatke v spremenljivki okolja (QUERYSTRING), kadar DOBI se uporablja. Ampak ko POST Uporabite, podatki obrazca se pošljejo v standardni vhodni tok (stdin), število bajtov, ki jih je treba prebrati, pa poda glava vsebine.

Priporočena uporaba

GET se priporoča pri oddaji obrazcev "idempotent" - tistih, ki "bistveno ne spremenijo stanja sveta". Z drugimi besedami, obrazci, ki vključujejo samo poizvedbe v bazi podatkov. Druga perspektiva je, da bo več idempotentnih poizvedb imelo enak učinek kot ena poizvedba. Če gre za posodobitve baze podatkov ali druga dejanja, kot je sprožitev e-poštnih sporočil, priporočamo uporabo POST.

Na spletnem dnevniku za razvijalce Dropbox:

brskalnik ne ve natančno, kaj določen obrazec HTML počne, če pa je obrazec predložen prek HTTP GET, brskalnik ve, da je varno samodejno znova poskusiti znova, če pride do napake v omrežju. Za obrazce, ki uporabljajo HTTP POST, morda ni varno znova, zato brskalnik najprej vpraša uporabnika za potrditev.

Zahteva "GET" je pogosto predpomnjena, medtem ko zahteva "POST" skoraj ne more biti. Za poizvedbene sisteme ima to lahko pomemben učinek, zlasti če so poizvedbeni nizi preprosti, saj lahko predpomnilniki služijo najpogostejšim poizvedbam.

V nekaterih primerih z uporabo POST se priporoča tudi pri idempotentnih poizvedbah:

Če bi podatki obrazca vsebovali znake, ki niso ASCII (na primer s poudarjenimi znaki), torej METHOD = "DOBI" načeloma ni uporaben, čeprav lahko deluje v praksi (predvsem za ISO latinične 1 znake).
Če je nabor podatkov obrazca velik - recimo, sto znakov - torej METHOD = "DOBI" lahko povzroči praktične težave pri implementacijah, ki ne prenesejo tako dolgih URL-jev.
Morda bi se radi izognili METHOD = "DOBI" da bi bilo uporabnikom manj vidno, kako obrazec deluje, zlasti zato, da bi "skrita" polja (INPUT TYPE = "HIDDEN") bolj skrita, če se ne prikažejo v URL-ju. Toda tudi če uporabljate skrita polja s METHOD = "POST", bodo še vedno prikazane v izvorni kodi HTML.

Kaj pa HTTPS?

Posodobljeno 15. maja 2015: POST ponuja, če uporabljate HTTPS (HTTP prek TLS / SSL) večjo varnost kot GET?

To je zanimivo vprašanje. Recite, da na spletno stran vložite zahtevo GET:

 DOBITE https://www.example.com/login.php?user=mickey&passwd=mini

Ob predpostavki, da se vaša internetna povezava nadzira, katere informacije o tej zahtevi bodo na voljo ostrostrelcu? Če se namesto tega uporablja POST in so podatki uporabnika in passwd vključeni v spremenljivke POST, bodo to bolj varne v primeru povezav HTTPS?

Odgovor je ne. Če vložite takšno zahtevo GET, bo napadalec nadziral vaš spletni promet le naslednje podatke:

Dejstvo, da ste vzpostavili povezavo HTTPS
Ime gostitelja - www.example.com
Skupna dolžina zahteve
Dolžina odgovora

Del poti URL-ja - to je dejanska zahtevana stran, pa tudi parametri poizvedbenega niza - so zaščiteni (šifrirani), medtem ko so na poti do ciljnega strežnika "čez žico", tj. Situacija je popolnoma enaka za zahteve POST.

Seveda spletni strežniki beležijo celoten URL v navadnem besedilu v svojih dostopnih dnevnikih; zato pošiljanje občutljivih informacij prek GET ni dobra ideja. To velja ne glede na to, ali se uporablja HTTP ali HTTPS.

Reference

wikipedia: POST (HTTP)
Metode zahteve HTTP
Objava HTTP - W3.org
HTTP Get - W3.org
Ali HTTPS skriva URL-je, do katerih dostopate? - Izmenjava stakov

Tehnologija