GET vs. POST

HTTP POST kéri, hogy szállítson további adatokat az ügyféltől (böngészőtől) az üzenet törzsében lévő kiszolgálóra. Ellentétben, KAP A kérelmek tartalmazzák az URL-ben az összes szükséges adatot. A HTML formában szereplő űrlapok bármelyik módszerrel megadhatók method = "POST" vagy method = "GET" (alapértelmezett) a elem. A megadott módszer határozza meg, hogy az űrlapadatokat hogyan kell kiszolgálni. Ha a módszer GET, akkor az összes űrlapadatot az URL kódolja, amelyet a akció URL lekérdezési karakterlánc-paraméterként. A POST használatával az űrlapadatok megjelennek a HTTP kérés üzenetében.

Összehasonlító táblázat

GET és POST összehasonlító diagram

	KAP	POST

Történelem	A paraméterek a böngésző előzményeiben maradnak, mert az URL részét képezik	A paramétereket nem menti a böngésző előzményei.
Leparkolt	Megjelölhető könyvjelzővel.	Nem lehet könyvjelzővel ellátni.
BACK gomb / újraküldés viselkedés	A GET kéréseket újra végrehajtják, de nem küldhetjük el újra a kiszolgálóra, ha a HTML-t a böngésző gyorsítótárában tároljuk.	A böngésző rendszerint figyelmezteti a felhasználót, hogy az adatokat újra be kell nyújtani.
Kódolási típus (enctype attribútum)	application / x-www-form-urlencoded	multipart / form-data vagy application / x-www-form-urlencoded Használjon többrészes kódolást bináris adatokhoz.
paraméterek	küldhetünk, de a paraméter adatok arra korlátozódnak, hogy mit tudunk beilleszteni a kérés sorba (URL). A legbiztonságosabb, ha kevesebb, mint 2K paramétert használ, néhány kiszolgáló akár 64K-t képes kezelni	Küldhet paramétereket, beleértve a fájlok feltöltését, a kiszolgálóra.
feltört	Könnyebben csapkodhat a forgatókönyvekkel	Nehezebb feltörni
Az űrlapadat-típus korlátozásai	Igen, csak ASCII karakterek engedélyezettek.	Korlátozások nélkül. A bináris adatok is megengedettek.
Biztonság	A GET kevésbé biztonságos a POST-hoz képest, mivel az elküldött adatok az URL része. Tehát menti a böngésző előzményeiben és a szerver naplóiban egyszerű szöveges formában.	A POST egy kicsit biztonságosabb, mint a GET, mivel a paramétereket nem tárolja a böngésző előzményeiben vagy a webszerver naplóiban.
Az űrlapadatok hosszának korlátozásai	Igen, mivel az űrlapadatok az URL-ben vannak, és az URL hossza korlátozott. A biztonságos URL-hossz korlátozása gyakran 2048 karakter, de böngészőn és webszerverenként eltérő.	Korlátozások nélkül
használhatóság	A GET módszert nem szabad használni jelszavak vagy más érzékeny információk küldésekor.	Jelszavak vagy más érzékeny információk küldésére használt POST-módszer.
Láthatóság	A GET módszer mindenki számára látható (ez megjelenik a böngésző címsorában), és korlátozza az elküldendő információk mennyiségét.	A POST módszer változói nem jelennek meg az URL-ben.
Gyorsítótárba	Tárolható	Nincs tárolva

Tartalom: GET vs POST

1 Az űrlap benyújtásának különbségei
- 1.1 Előnyök és hátrányok
2 A szerveroldali feldolgozás különbségei
3 Ajánlott használat
4 Mi a helyzet a HTTPS-rel??
5 Hivatkozások

Az űrlap benyújtásának különbségei

Az alapvető különbség a Method = "GET" és MÓDSZER = "POST" az, hogy megfelelnek különböző HTTP kérések, a HTTP előírásokban meghatározottak szerint. A benyújtási folyamat mindkét módszer esetében ugyanúgy kezdődik - egy űrlapadat-készletet a böngésző állít össze, majd a kódolt módon a enctype tulajdonság. mert MÓDSZER = "POST az enctype attribútum lehet multipart / form-data vagy application / x-www-form-urlencoded, mivel a Method = "GET", csak application / x-www-form-urlencoded megengedett. Ezt az űrlapadatkészletet ezután továbbítják a szerverre.

A METHOD = "GET" metódussal történő benyújtáshoz a böngésző egy URL-t készít a akció attribútum, kiegészítve a ? hozzá, majd hozzáfűzi az űrlapadatkészletet (az alkalmazás / x-www-form-urlencoded tartalomtípussal kódolva). Ezután a böngésző úgy dolgozza fel ezt az URL-t, mintha egy linket követne (vagy mintha a felhasználó közvetlenül írta volna az URL-t). A böngésző felosztja az URL-t részekre és felismeri a gazdagépet, majd elküldi az adott gazdagépnek egy GET-kérést az URL többi részével argumentumként. A szerver onnan veszi. Vegye figyelembe, hogy ez a folyamat azt jelenti, hogy az űrlapadatok ASCII kódokra vannak korlátozva. Különös figyelmet kell fordítani más típusú karakterek kódolására és dekódolására, ha azokat az URL-en keresztül ASCII formátumban továbbítják.

Űrlap benyújtása METHOD = "POST" használatával a POST kérés elküldését eredményezi a akció attribútum és egy üzenet, amelyet a enctype tulajdonság.

Érvek és ellenérvek

Mivel az űrlapadatokat az URL részeként küldjük, amikor KAP használt --

Az űrlapadatok ASCII kódokra vannak korlátozva. Különös figyelmet kell fordítani más típusú karakterek kódolására és dekódolására, ha azokat az URL-en keresztül ASCII formátumban továbbítják. Másrészt a bináris adatok, képek és egyéb fájlok mind beküldhetők MÓDSZER = "POST"
Az összes kitöltött űrlapadat látható az URL-ben. Ezenkívül a felhasználó böngészési előzményeiben / naplójában is tárolja. Ezek a kérdések miatt KAP kevésbé biztonságos.
Azonban az űrlapadatoknak az URL részeként történő elküldésének egyik előnye az, hogy meg lehet adni az URL-címeket könyvjelzővel és közvetlenül felhasználhatja őket, és teljesen megkerülheti az űrlap kitöltési folyamatát.
Az űrlapadatok küldésének korlátozása korlátozott, mivel az URL hossza korlátozott.
A szkript-gyerek könnyebben feltárhatja a rendszer sebezhetőségét, hogy feltörje azt. Például a Citibankot feltörték azáltal, hogy megváltoztatta a számlaszámokat az URL-sorban.^[1] Természetesen a tapasztalt hackerek vagy a webfejlesztők ki is tehetik az ilyen biztonsági réseket, még akkor is, ha POST-ot használnak; csak egy kicsit nehezebb. Általában véve a szervernek gyanakvónak kell lennie az ügyfél által küldött adatokkal szemben, és védenie kell a nem biztonságos közvetlen objektumhivatkozásokat.

A szerveroldali feldolgozás különbségei

A benyújtott űrlapadatok feldolgozása elvben attól függ, hogy azokat elküldték-e Method = "GET" vagy MÓDSZER = "POST". Mivel az adatok különböző módon vannak kódolva, különböző dekódolási mechanizmusokra van szükség. Így általában véve a METHOD megváltoztatása szükségessé teheti a szkript megváltoztatását, amely feldolgozza a benyújtást. Például, amikor a CGI felületet használja, a szkript akkor kapja meg az adatokat egy környezeti változóban (QUERYSTRING), amikor KAP használt. De amikor POST kerül felhasználásra, az űrlapadatokat a standard bemeneti adatfolyam továbbítja (stdin) és az olvasandó bájtok számát a Tartalomhossz fejléc adja meg.

Ajánlott használat

A GET ajánlott "idempotens" nyomtatványok benyújtásakor - azok, amelyek "nem változtatják meg jelentősen a világ állapotát". Más szavakkal, csak az adatbázis lekérdezéseket tartalmazó űrlapok. Egy másik szempont az, hogy több idempotens lekérdezés ugyanolyan hatással lesz, mint egyetlen lekérdezés. Ha adatbázis-frissítésekre vagy egyéb tevékenységekre, például elindító e-mailekre van szükség, a POST használata ajánlott.

A Dropbox fejlesztői blogjából:

egy böngésző nem tudja pontosan, mit tesz egy adott HTML űrlap, de ha az űrlapot HTTP GET útján nyújtják be, akkor a böngésző tudja, hogy hálózati hiba esetén biztonságos az újbóli beküldés. A HTTP POST-t használó űrlapok esetén nem biztos, hogy újrapróbálkozik, így a böngésző először megerősítést kér a felhasználótól.

A „GET” kérés gyakran gyorsítótárban tárolható, míg a „POST” kérés aligha lehet. A lekérdező rendszereknél ez jelentős hatékonysági hatással lehet, különösen, ha a lekérdezési karakterláncok egyszerűek, mivel a gyorsítótárak szolgálhatják a leggyakoribb lekérdezéseket.

Bizonyos esetekben a POST még idempotens lekérdezések esetén is ajánlott:

Ha az űrlapadatok nem ASCII karaktereket tartalmaznának (például ékezetes karakterek), akkor Method = "GET" elvben nem alkalmazható, bár a gyakorlatban működhet (főleg az ISO Latin 1 karaktereknél).
Ha az űrlapadatkészlet nagy - mondjuk, száz karakter - akkor Method = "GET" gyakorlati problémákat okozhat azokkal a megvalósításokkal, amelyek nem tudják kezelni a hosszú URL-eket.
Érdemes elkerülni Method = "GET" annak érdekében, hogy kevésbé legyen látható a felhasználók számára az űrlap működéséről, különösen annak érdekében, hogy a "rejtett" mezőket (INPUT TYPE = "HIDDEN") rejtettebbé tegyék azáltal, hogy nem jelennek meg az URL-en. De akkor is, ha rejtett mezőket használ MÓDSZER = "POST", továbbra is megjelennek a HTML forráskódban.

Mi a helyzet a HTTPS-szel??

Frissítve 2015. május 15 .: Különösen a HTTPS (HTTP over TLS / SSL) használata esetén a POST nem nyújt több biztonságot, mint a GET?

Ez egy érdekes kérdés. Tegyük fel, hogy GET kérést küld egy weboldalra:

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

Feltéve, hogy az internetkapcsolatot megfigyeljük, milyen információkkal fog rendelkezni a snooper számára erről a kérésről? Ha ehelyett POST-t használnak, és a felhasználói és a passwd-adatok szerepelnek a POST-változókban, akkor a HTTPS-kapcsolatok esetén ez biztonságosabb lesz?

A válasz nem. Ha ilyen GET-kérelmet nyújt be, akkor csak a következő információkat fogja tudni az internetes forgalmat figyelő támadó:

Az a tény, hogy létrejött egy HTTPS kapcsolat
A gazdagép neve - www.example.com
A kérés teljes hossza
A válasz hossza

Az URL elérési útja - azaz a ténylegesen kért oldal, valamint a lekérdezés karakterlánca paraméterei - védettek (titkosítva), miközben "a huzal fölött" vannak, azaz a rendeltetési kiszolgáló felé vezető úton vannak. A helyzet pontosan ugyanaz a POST kéréseknél.

Természetesen a webszerverek hajlamosak a teljes URL-t egyszerű szövegben naplózni a hozzáférési naplókban; így a bizalmas információk GET-en keresztüli küldése nem jó ötlet. Ez függetlenül attól, hogy HTTP-t vagy HTTPS-t használnak-e.

Irodalom

wikipedia: POST (HTTP)
HTTP kérési módszerek
HTTP-üzenet - W3.org
HTTP Get - W3.org
Elrejti a HTTPS a megkeresett URL-eket? - Veremcsere

Technológia