GET vs. POST

HTTP LÄHETTÄÄ pyytää toimittamaan lisätietoja asiakkaalta (selaimelta) viestin rungon palvelimelle. Verrattuna, SAADA pyynnöt sisältävät kaikki vaadittavat tiedot URL-osoitteessa. HTML-lomakkeissa voidaan käyttää kumpaakin menetelmää määrittämällä Menetelmä = "post" tai Menetelmä = "GET" (oletus) elementti. Määritetty menetelmä määrittää, kuinka lomaketiedot lähetetään palvelimelle. Kun menetelmä on GET, kaikki lomaketiedot koodataan URL-osoitteeseen, joka lisätään toiminta URL kyselymerkkijonoparametreina. POST-muodossa lomaketiedot näkyvät HTTP-pyynnön viestin rungossa.

Vertailutaulukko

GET vs. POST-vertailutaulukko

	SAADA	LÄHETTÄÄ

Historia	Parametrit pysyvät selaimen historiassa, koska ne ovat osa URL-osoitetta	Parametreja ei tallenneta selaimen historiaan.
Muistio	Voidaan merkitä kirjanmerkkeihin.	Ei voida merkitä kirjanmerkkeihin.
BACK-painike / lähetä toiminta uudelleen	GET-pyynnöt suoritetaan uudelleen, mutta niitä ei voida lähettää uudelleen palvelimelle, jos HTML on tallennettu selaimen välimuistiin.	Selain yleensä ilmoittaa käyttäjälle, että tiedot on toimitettava uudelleen.
Koodaustyyppi (enctype-attribuutti)	application / x-www-lomakkeella-urlencoded	multipart / form-data tai application / x-www-form-urlencoded Käytä moniosaista koodausta binaariseen dataan.
parametrit	voi lähettää, mutta parametritiedot ovat rajoitettu siihen, mitä voimme täyttää pyyntöriville (URL). Turvallisin käyttää alle 2 kt parametreja, jotkut palvelimet käsittelevät jopa 64 kt	Voi lähettää parametrejä, tiedostojen lähettäminen mukaan lukien, palvelimelle.
hakkeroitu	Helvempi hakkerointi käsikirjoittajille	Vaikeampi hakata
Rajoitukset lomaketietotyypille	Kyllä, vain ASCII-merkit ovat sallittuja.	Ei rajoituksia. Binaaritiedot ovat myös sallittuja.
turvallisuus	GET on vähemmän turvallinen verrattuna POSTiin, koska lähetetyt tiedot ovat osa URL-osoitetta. Joten se tallennetaan selaimen historiaan ja palvelinlokeihin selvätekstinä.	POST on vähän turvallisempi kuin GET, koska parametreja ei tallenneta selaimen historiaan tai Web-palvelimen lokiin.
Rajoitukset lomaketiedon pituuteen	Kyllä, koska lomaketiedot ovat URL-osoitteessa ja URL-osoitteiden pituutta on rajoitettu. Turvallisen URL-osoitteen pituusrajoitus on usein 2048 merkkiä, mutta vaihtelee selaimen ja Web-palvelimen mukaan.	Ei rajoituksia
Käytettävyys	GET-menetelmää ei tule käyttää salasanojen tai muun arkaluontoisen tiedon lähettämisessä.	POST-menetelmä, jota käytetään salasanojen tai muun arkaluontoisen tiedon lähettämisessä.
näkyvyys	GET-menetelmä on kaikkien nähtävissä (se näkyy selaimen osoiterivillä), ja sillä on rajoitettu lähetettävien tietojen määrä.	POST-menetelmän muuttujia ei näytetä URL-osoitteessa.
välimuistissa	Voidaan tallentaa välimuistiin	Ei välimuistissa

Sisältö: GET vs. POST

1 Ero lomakkeen toimittamisessa
- 1.1 Hyödyt ja haitat
2 eroja palvelinpuolen prosessoinnissa
3 Suositeltu käyttö
4 Entä HTTPS?
5 Viitteet

Eroja lomakkeiden toimittamisessa

Perusteellinen ero Method = "GET" ja Method = "POST" on se, että ne vastaavat erilaiset HTTP-pyynnöt, kuten määritelty HTTP-eritelmissä. Molempien menetelmien lähetysprosessi alkaa samalla tavalla - selain rakentaa lomaketietoryhmän ja koodaa sitten sen määrittelemällä tavalla. enctype määrite. varten Method = "POST enctype ominaisuus voi olla multipart / form-data tai application / x-www-lomakkeella-urlencoded, kun taas Method = "GET", vain application / x-www-lomakkeella-urlencoded on sallittu. Tämä lomaketiedosto siirretään sitten palvelimelle.

Lomakkeen lähettämistä varten menetelmällä METHOD = "GET" selain rakentaa URL-osoitteen ottamalla arvo toiminta attribuutti, liittämällä a ? lisäämällä siihen lomaketietosarjan (koodattu käyttämällä sovellusta / x-www-muoto-urlenkoodattua sisältötyyppiä). Tämän jälkeen selain käsittelee tätä URL-osoitetta seuraten linkkiä (tai kuin jos käyttäjä olisi kirjoittanut URL-osoitteen suoraan). Selain jakaa URL-osoitteen osiin ja tunnistaa isäntän, lähettää sitten tälle isäntälle GET-pyynnön loput URL-osoitteen perusteena. Palvelin vie sen sieltä. Huomaa, että tämä prosessi tarkoittaa, että lomaketiedot on rajoitettu ASCII-koodeihin. Erityistä varovaisuutta tulee koodata ja dekoodata muun tyyppisiä merkkejä siirrettäessä niitä URL-osoitteen kautta ASCII-muodossa.

Lomakkeen toimittaminen METHOD = "POST" aiheuttaa POST-pyynnön lähettämisen käyttämällä toiminta - määritteen ja viestin, joka on luotu enctype ominaisuus.

Hyvät ja huonot puolet

Koska lomaketiedot lähetetään osana URL-osoitetta, kun SAADA käytetään --

Lomaketiedot on rajoitettu ASCII-koodeihin. Erityistä varovaisuutta tulee koodata ja dekoodata muun tyyppisiä merkkejä siirrettäessä niitä URL-osoitteen kautta ASCII-muodossa. Toisaalta, binaaritiedot, kuvat ja muut tiedostot voidaan kaikki lähettää kautta Method = "POST"
Kaikki täytetyt lomaketiedot näkyvät URL-osoitteessa. Lisäksi se on tallennettu käyttäjän selaimen historiaan / lokiin. Nämä asiat tekevät SAADA vähemmän turvallisia.
Yksi URL-osoitteen muodossa lähetettävien lomaketietojen etu on kuitenkin se, että URL-osoitteet voidaan merkitä kirjanmerkkeihin ja käyttää niitä suoraan ja ohittaa lomakkeen täyttöprosessi kokonaan..
Lomaketietojen lähettämiselle on rajoitus, koska URL-osoitteiden pituudet ovat rajoitetut.
Komentosarjan kiddies voivat helpommin paljastaa järjestelmän haavoittuvuuksia hakkeroidaksesi sen. Esimerkiksi Citibankiin hakkeroitiin muuttamalla tilinumeroita URL-osoitteessa.^[1] Kokenut hakkerit tai web-kehittäjät voivat tietysti paljastaa tällaiset haavoittuvuudet, vaikka POST: ta käytetään. se on vain vähän vaikeampaa. Yleensä palvelimen on oltava epävarma kaikista asiakkaan lähettämistä tiedoista ja suojattava epävarmoilta suoraobjektiviittauksilta.

Erot palvelinpuolen prosessoinnissa

Lähetettyjen lomaketietojen käsittely riippuu periaatteessa siitä, lähetetäänkö ne Method = "GET" tai Method = "POST". Koska dataa koodataan eri tavoin, tarvitaan erilaisia dekoodausmekanismeja. Siten METHODin muuttaminen voi yleensä vaatia muutosta komentosarjasta, joka käsittelee lähettämistä. Esimerkiksi käytettäessä CGI-liittymää skripti vastaanottaa tiedot ympäristömuuttujassa (QUERYSTRING), kun SAADA käytetään. Mutta kun LÄHETTÄÄ käytetään, lomaketiedot siirretään vakiosyöttövirrassa (stdin) ja luettavien tavujen lukumäärä annetaan Sisältöpituus-otsikossa.

Suositeltu käyttö

GET-suositusta suositellaan toimitettaessa "idempotentteja" lomakkeita - sellaisia, jotka eivät "muuta merkittävästi maailman tilaa". Toisin sanoen lomakkeet, joihin liittyy vain tietokantakyselyjä. Toinen näkökulma on, että useilla idempotentteilla kyselyillä on sama vaikutus kuin yhdellä kyselyllä. Jos tietokannan päivityksiä tai muita toimia, kuten käynnistäviä sähköpostiviestejä, on käytettävä POST-sovellusta.

Dropbox-kehittäjäblogista:

selain ei tiedä tarkalleen, mitä tietty HTML-muoto tekee, mutta jos lomake lähetetään HTTP GET: n kautta, selain tietää, että on turvallista yrittää uudelleen lähettää tiedosto automaattisesti, jos kyseessä on verkkovirhe. HTTP POSTia käyttävissä lomakkeissa ei ehkä ole turvallista yrittää uudelleen, joten selain kysyy käyttäjältä ensin vahvistusta.

"GET" -pyyntö on usein välimuisti, kun taas "POST" -pyyntö tuskin voi olla. Kyselyjärjestelmillä tällä voi olla huomattava tehokkuusvaikutus, varsinkin jos kyselyjonot ovat yksinkertaisia, koska välimuistit saattavat palvella yleisimpiä kyselyjä.

Joissakin tapauksissa käyttämällä LÄHETTÄÄ suositellaan jopa idempotentteihin kyselyihin:

Jos lomaketiedot sisältäisivät muita kuin ASCII-merkkejä (kuten korostettuja merkkejä) Method = "GET" ei ole periaatteessa soveltumaton, vaikka se saattaa toimia käytännössä (pääasiassa ISO Latin 1 -merkkien kohdalla).
Jos lomaketietoaineisto on suuri - sanotaan satoja merkkejä - sitten Method = "GET" saattaa aiheuttaa käytännön ongelmia toteutuksissa, jotka eivät pysty käsittelemään näitä pitkiä URL-osoitteita.
Haluat ehkä välttää Method = "GET" jotta se olisi vähemmän näkyvä käyttäjille kuinka lomake toimii, etenkin jotta piilotetut kentät (INPUT TYPE = "HIDDEN") piilottuisivat, koska niitä ei näytetä URL-osoitteessa. Mutta vaikka käytät piilotettuja kenttiä kanssa Method = "POST", ne näkyvät edelleen HTML-lähdekoodissa.

Entä HTTPS?

Päivitetty 15. toukokuuta 2015: Erityisesti käytettäessä HTTPS: ää (HTTP TLS / SSL: n yli) POST tarjoaa enemmän turvallisuutta kuin GET?

Tämä on mielenkiintoinen kysymys. Oletetaan, että teet GET-pyynnön verkkosivulle:

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

Jos oletetaan, että Internet-yhteyttäsi tarkkaillaan, mitä tietoja tästä pyynnöstä saa snooper? Jos POST: ta käytetään sen sijaan ja käyttäjän ja passwd-tiedot sisältyvät POST-muuttujiin, ovatko ne turvallisempia HTTPS-yhteyksissä?

Vastaus on ei. Jos teet tällaisen GET-pyynnön, verkkoliikennettä seuraava hyökkääjä tietää vain seuraavat tiedot:

Se, että loit HTTPS-yhteyden
Isäntänimi - www.example.com
Pyynnön kokonaispituus
Vastauksen pituus

URL-osoitteen polkuosa - eli todellinen pyydetty sivu, samoin kuin kyselymerkkijonoparametrit - ovat suojattuja (salattuja), kun ne ovat "langan yli", ts. Kuljetettaessa matkalla kohdepalvelimelle. Tilanne on täsmälleen sama POST-pyynnöissä.

Tietysti web-palvelimet yleensä kirjaavat koko URL-osoitteen selkeästi pääsylokeihin; joten arkaluontoisen tiedon lähettäminen GET: n kautta ei ole hyvä idea. Tämä pätee riippumatta siitä käytetäänkö HTTP tai HTTPS.

Viitteet

wikipedia: POST (HTTP)
HTTP-pyyntömenetelmät
HTTP-viesti - W3.org
HTTP-Get - W3.org
Piilottaako HTTPS käyttämäsi URL-osoitteet? - Pinovaihto

tekniikka