GET vs POST

HTTP POST taotleb kliendi (brauseri) kaudu sõnumi põhiosa serverisse täiendavate andmete esitamist. Seevastu, SAA taotlused sisaldavad URL-is kõiki nõutavaid andmeid. HTML-i vormides saab täpsustada mõlemat meetodit meetod = "POST" või meetod = "GET" (vaikeseade) element. Täpsustatud meetod määrab, kuidas vormiandmeid serverile esitatakse. Kui meetod on GET, kodeeritakse kõik vormi andmed URL-i lisatud URL-i tegevus URL päringu stringi parameetrina. POST-i korral kuvatakse vormi andmed HTTP-päringu sõnumi kehas.

Võrdlusdiagramm

GET versus POST võrdlustabel

	SAA	POST

Ajalugu	Parameetrid jäävad brauseri ajalukku, kuna need on osa URL-ist	Parameetreid ei salvestata brauseri ajalukku.
Järjehoidja	Võib järjehoidjate hulka lisada.	Ei saa järjehoidjate hulka lisada.
Nupp TAGASI / käitumise uuesti esitamine	GET-taotlused täidetakse uuesti, kuid neid ei tohi serverisse uuesti esitada, kui HTML-i on brauseri vahemällu salvestatud.	Tavaliselt hoiatab brauser kasutajat, et andmed tuleb uuesti esitada.
Kodeeringu tüüp (enctype atribuut)	rakendus / x-www-vorm-urlencoded	multipart / form-data või application / x-www-form-urlencoded Kasutage binaarsete andmete jaoks mitmeosalist kodeeringut.
Parameetrid	saab saata, kuid parameetri andmed piirduvad sellega, mida me saame päringureale (URL) lisada. Ohutum on kasutada vähem kui 2K parameetreid, mõned serverid töötavad kuni 64K	Saab saata parameetreid, sealhulgas failide üleslaadimist serverisse.
Häkitud	Stsenaariumi kiddies on lihtsam häkkida	Keerulisem häkkida
Vormi andmetüübi piirangud	Jah, lubatud on ainult ASCII tähemärgid.	Piiranguteta. Lubatud on ka binaarandmed.
Turvalisus	GET on POST-iga vähem turvaline, kuna saadetud andmed on osa URL-ist. Nii salvestatakse see brauseri ajalukku ja serveri logidesse tavalises tekstis.	POST on pisut turvalisem kui GET, kuna parameetreid ei salvestata brauseri ajaloos ega veebiserveri logides.
Vormi andmete pikkuse piirangud	Jah, kuna vormi andmed on URL-is ja URL-i pikkus on piiratud. Ohutu URL-i pikkuse piirang on sageli 2048 tähemärki, kuid see sõltub brauserist ja veebiserverist.	Piiranguteta
Kasutatavus	Paroolide või muu tundliku teabe saatmisel ei tohiks GET-meetodit kasutada.	Paroolide või muu tundliku teabe saatmisel kasutatav POST-meetod.
Nähtavus	GET-meetod on kõigile nähtav (see kuvatakse brauseri aadressiribal) ja sellel on edastatava teabe hulga piirangud.	POST-meetodi muutujaid URL-is ei kuvata.
Vahemällu	Võib vahemällu salvestada	Pole vahemällu salvestatud

Sisu: GET vs POST

1 Vormi esitamise erinevused
- 1.1 plussid ja miinused
2 Erinevusi serveripoolses töötlemises
3 Soovituslik kasutamine
4 Aga HTTPS?
5 viidet

Erinevused vormi esitamisel

Põhimõtteline erinevus METHOD = "SAA" ja METHOD = "POST" on see, et nad vastavad erinevad HTTP päringud, nagu on määratletud HTTP spetsifikatsioonides. Mõlema meetodi esitamisprotsess algab samal viisil - brauser konstrueerib vormiandmekogumi ja kodeerib seejärel enktüüp atribuut. Sest MEETOD = "POST enktüüp atribuut võib olla mitme osa / vormi andmed või rakendus / x-www-vorm-urlencoded, arvestades, et jaoks METHOD = "SAA", ainult rakendus / x-www-vorm-urlencoded on lubatud. Seejärel edastatakse see vormi andmekogum serverisse.

Vormi esitamiseks METHOD = "GET" abil konstrueerib brauser URL-i, võttes väärtuse tegevus atribuut, lisades a ? sellele lisades seejärel vormiandmekogumi (kodeeritud kasutades rakenduse / x-www-vorm-urlencoded sisutüüpi). Seejärel töötleb brauser seda URL-i, järgides linki (või nagu kasutaja oleks URL-i otse kirjutanud). Brauser jagab URL-i osadeks ja tunneb ära masina, saadab seejärel sellele hostile GET-päringu koos ülejäänud URL-iga argumendina. Server võtab selle sealt ära. Pange tähele, et see protsess tähendab, et vormi andmed on piiratud ASCII koodidega. Erilist tähelepanu tuleb pöörata muud tüüpi märkide kodeerimisele ja dekodeerimisele, kui neid URL-i kaudu ASCII-vormingus edastada.

Vormi esitamine meetodiga METHOD = "POST" põhjustab POST-päringu saatmise, kasutades väärtust tegevus atribuut ja sõnum, mis on loodud vastavalt enktüüp atribuut.

Plussid ja miinused

Kuna vormi andmed saadetakse URL-i osana millal SAA kasutatakse --

Vormi andmed on piiratud ASCII koodidega. Erilist tähelepanu tuleb pöörata muud tüüpi märkide kodeerimisele ja dekodeerimisele, kui neid URL-i kaudu ASCII-vormingus edastada. Teisest küljest saab binaarandmeid, pilte ja muid faile esitada ka läbi METHOD = "POST"
Kõik täidetud vormi andmed on URL-is nähtavad. Lisaks salvestatakse see ka kasutaja veebibrauseri ajaloos / logides. Need küsimused teevad SAA vähem turvaline.
URL-i osana saadetavate vormiandmete üheks eeliseks on aga see, et URL-id saab järjehoidjate hulka lisada ja neid otse kasutada ning vormide täitmise protsessist täielikult mööda minna.
Vormiandmete saatmise maht on piiratud, kuna URL-i pikkused on piiratud.
Skripti kiddies saavad süsteemi häkkimiseks hõlpsamini süsteemi haavatavusi. Näiteks hävitati Citibanki, muutes URL-i stringi kontonumbreid.^[1] Muidugi saavad kogenud häkkerid või veebiarendajad sellised turvaaukud paljastada ka POST-i kasutamisel; see on lihtsalt natuke raskem. Üldiselt peab server olema kliendi saadetud andmete suhtes kahtlane ja kaitsma ebaturvaliste otseobjektide viidete eest.

Erinevused serveripoolses töötlemises

Esitatud vormi andmete töötlemine sõltub põhimõtteliselt sellest, kas need saadetakse koos METHOD = "SAA" või METHOD = "POST". Kuna andmeid kodeeritakse erineval viisil, on vaja erinevaid dekodeerimismehhanisme. Seega võib METHODI muutmine tingimata muuta skripti, mis töötleb esitamist. Näiteks CGI-liidese kasutamisel võtab skript andmeid keskkonnamuutuja (QUERYSTRING) ajal SAA kasutatakse. Aga kui POST kasutatakse, vormi andmed edastatakse standardses sisendvoos (stdin) ja loetavate baitide arv on toodud päise Sisu pikkus abil.

Soovituslik kasutamine

GET-i soovitatakse esitada idempotentsete vormide esitamisel - vormidel, mis "ei muuda oluliselt maailma olukorda". Teisisõnu, vormid, mis hõlmavad ainult andmebaasipäringuid. Teine perspektiiv on see, et mitmel idempotentsel päringul on sama efekt kui ühel päringul. Kui andmebaasi värskendused või muud toimingud, näiteks e-kirjade käivitamine, on soovitatav kasutada POST-i.

Dropboxi arendaja ajaveebist:

brauser ei tea täpselt, mida konkreetne HTML-vorm teeb, kuid kui vorm edastatakse HTTP GET-i kaudu, teab brauser, et on turvaline võrgutõrke korral esitust uuesti korrata. Vormide puhul, mis kasutavad HTTP POST-i, ei pruugi uuesti proovimine olla ohutu, nii et brauser küsib kasutajalt kõigepealt kinnitust.

GET-taotlus on sageli vahemäluruumis, POST-päring aga vaevalt saab. Päringusüsteemide jaoks võib see avaldada märkimisväärset tõhusust, eriti kui päringustringid on lihtsad, kuna vahemälud võivad pakkuda kõige sagedamini esinevaid päringuid.

Teatud juhtudel kasutades POST on soovitatav isegi ideaalpäringute korral:

Kui vormi andmed sisaldaks mitte-ASCII-tähemärke (näiteks rõhumärkidega) METHOD = "SAA" on põhimõtteliselt mittekohaldatav, ehkki see võib praktikas töötada (peamiselt ISO ladina 1 tähtede puhul).
Kui vormi andmekogum on suur - ütleme, sadu tähemärki - siis METHOD = "SAA" võib põhjustada praktilisi probleeme rakendustega, mis ei saa nii pikkade URL-idega hakkama.
Võite seda vältida METHOD = "SAA" selleks, et vorm oleks kasutajate jaoks vähem nähtav, eriti selleks, et muuta peidetud väljad (INPUT TYPE = "HIDDEN") varjatumaks, kuna neid URL-is ei kuvata. Kuid isegi kui kasutate varjatud välju koos METHOD = "POST", nad ilmuvad endiselt HTML-i lähtekoodis.

Aga HTTPS?

Värskendatud 15. mai 2015: Kas HTTPS-i (HTTP üle TLS / SSL) kasutamisel pakub POST rohkem turvalisust kui GET?

See on huvitav küsimus. Oletame, et esitate GET-i taotluse veebisaidile:

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

Kui eeldatakse, et teie Interneti-ühendust jälgitakse, siis milline teave selle päringu kohta on snooperil saadaval? Kui selle asemel kasutatakse POST-i ja kasutaja- ning parooliandmed on kaasatud POST-i muutujatesse, on see HTTPS-ühenduste korral turvalisem?

Vastus on eitav. Kui esitate sellise GET-päringu, on teie veebiliiklust jälgiv ründaja teada ainult järgmist teavet:

Fakt, et lõite HTTPS-ühenduse
Hostinimi - www.example.com
Taotluse kogupikkus
Vastuse pikkus

URL-i teeosa - st tegelik taotletud leht ja päringustringi parameetrid - on kaitstud (krüptitud), kui nad on "üle juhtme", st kui nad on teel sihtkohta serverisse. POST-päringute puhul on olukord täpselt sama.

Muidugi, veebiserverid kipuvad logima kogu URL-i oma juurdepääsu logidesse lihttekstina; seega pole tundliku teabe saatmine GET-i kaudu hea mõte. See kehtib sõltumata sellest, kas kasutatakse HTTP või HTTPS.

Viited

vikipeedia: POST (HTTP)
HTTP päringumeetodid
HTTP-postitus - W3.org
HTTP hankimine - W3.org
Kas HTTPS peidab juurdepääsu URL-idele? - Stack Exchange

Tehnoloogia