A HTTP különböző módokat határoz meg a szerverrel való interakcióra, és négy alapvető módszer létezik: GET, POST, PUT és DELETE. Az URL teljes neve egy erőforrás-leíró, gondolhatjuk így: URL cím, amely egy hálózaton lévő erőforrás leírására szolgál, és a GET, POST, PUT, DELETE HTTP-ben megfelel a négy műveletnek: az erőforrás ellenőrzése, módosítása, hozzáadása és törlése. Ezen a ponton már általános megértésed van: a GET-et általában erőforrás-információk megszerzésére/lekérdezésére használják, míg a POST-ot általában az erőforrás-információk frissítésére.
1. A HTTP specifikáció szerint a GET-et az információkeresésre használják, és biztonságosnak és idempotensnek kell lennie.
(1). Az úgynevezett biztonság azt jelenti, hogy a műveletet információ megszerzésére használják, nem pedig módosításra. Más szóval, a GET kéréseknek általában nem lehetnek mellékhatásai. Vagyis csak erőforrás-információkat kap, akárcsak az adatbázis lekérdezés, és nem módosítja, nem adja meg az adatokat, és nem befolyásolja az erőforrás állapotát.
* Megjegyzés: A biztonság jelentése itt csak a nem módosított információkra vonatkozik.
(2). idempotens azt jelenti, hogy több kérés ugyanazzal az URL-re ugyanazt az eredményt adja meg.
Gyakorlati alkalmazásban azonban a fenti két szabályozás nem olyan szigorú. Példák mások cikkeinek idézésére: Például egy hírportál címlapja folyamatosan frissül. Míg a második kérés más hírsort ad vissza, a művelet továbbra is biztonságosnak és idempotensnek számít, mert mindig a jelenlegi híreket adja vissza. Alapvetően, ha a cél az, hogy amikor a felhasználó megnyit egy linket, biztos lehet benne, hogy az ő szemszögéből nem változott meg az erőforrás.
2. A HTTP specifikáció szerint a POST egy olyan kérést képvisel, amely módosíthatja a szerver erőforrását. Folytatva a fenti példát idézve: Még mindig hírek Vegyük példának a weboldalt, az olvasóknak saját hozzászólásaikat kell közzétenniük a hírekhez, mert az oldal forrásai eltérnek a hozzászólás beküldése után, vagy módosítva az erőforrásokat.
A fentiek nagyjából tárgyalják a GET és POST néhány elvét a HTTP specifikációban. Azonban sokan nem követik a HTTP specifikációt, amikor ténylegesen csinálják, ami számos okot vezethet erre a problémára, például:
1. Sokan használják a GET-et az erőforrások frissítésére, mert a POST-hoz a FORM-ra kell menniük, ami kicsit problémás lesz.
2. Az erőforrások hozzáadása, törlése, módosítása és ellenőrzése valójában GET/POST segítségével is elvégezhető, PUT és DELETE használata nélkül.
3. Egy másik az, hogy a korai Web MVC kerettervezők nem kezelték tudatosan az URL-eket absztrakt forrásként, így komoly probléma, hogy a hagyományos Web MVC keretrendszer alapvetően csak két HTTP módszert, a GET és POST módszert támogatja, de nem támogatja a PUT és DELETE módszereket.
* Rövid magyarázat az MVC-ről: Az MVC eredetileg az asztali programban létezett, az M az adatmodellre, a V a felhasználói felületre, C pedig a vezérlőre. Az MVC használatának célja, hogy szétválasszuk az M és V megvalósítási kódját, így ugyanaz a program különböző reprezentációkat használhat.
A fenti 3 pont általában a régi stílust írja le (a HTTP specifikáció szigorú betartása nélkül), az architektúra fejlesztésével most már a REST (Representational State Transfer) létezik, amely támogatja a HTTP specifikációt.
Miután beszéltünk a fő problémáról, nézzük meg a GET és POST közötti különbséget a felületi jelenségből:
1. A GET kérés adatai az URL-hez kerülnek csatolásra (azaz az adatokat a HTTP protokoll fejlécében helyezik el), és a ? Oszd szét az URL-t és továbbítsd az adatokat, és a paraméterek a &-val kapcsolódnak össze, például: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Ha az adatok angol betűk/számok, küldjék úgy, ahogy vannak, ha szóköz, konvertáld +-ra, ha kínai/más karakterek, akkor közvetlenül titkosítsuk a láncsort BASE64-gyel, hogy mintát kapj, például: %E4%BD%A0%E5%A5%BD, ahol XX a %XX-ben az ASCII, amelyet a hexadecimális szimbólum képvisel.
A POST a beküldött adatokat a HTTP csomag törzsébe helyezi.
2. "A GET módszer által benyújtott maximális adat csak 1024 bájt lehet, elméletileg nincs korlát a POST-ra, és nagy mennyiségű adat lehet átvinni, akár 80KB IIS4-ben és 100KB IIS5-ben"??!
A fenti mondat más cikkekről utalva, valójában téves és pontatlan ezt mondani:
(1). Először is, "a GET módszerrel beküldött adatok legfeljebb 1024 bájt" lehetnek, mert a GET URL-en keresztül küld adatokat, így a GET által beküldhető adatok mennyisége közvetlenül függ az URL hosszához. Valójában nincs felső paraméterkorlát az URL-ekre, és a HTTP protokoll specifikációja sem korlátozza az URL-ek hosszát. Ez a korlát egy adott böngésző és szerver által bevezetett korlátozás. Az IE URL hosszának korlátja 2083 bájt (2K+35). Más böngészőknél, mint a Netscape, FireFox stb. esetében nincs elméleti hosszkorlát, és ez a korlát az operációs rendszer támogatásától függ.
Fontos megjegyezni, hogy ez korlátozza az egész URL hosszát, nem csak a paraméterérték adathosszát. [Lásd 5. hivatkozás]
(2). Elméletileg a POST-nak nincs méretkorlátja, a HTTP protokoll specifikációjának nincs méretkorlátja, és pontatlan azt mondani, hogy "80K/100K méretkorlát van a POST adatokra", és nincs korlát a POST adatokra, és a szerver kezelőjének feldolgozó teljesítménye játszik korlátozó szerepet.
ASP programok esetén a Request objektum 100K adathossz-korláttal rendelkezik minden űrlapmező feldolgozásakor. De az Request.BinaryRead esetében nincs ilyen korlátozás.
Ebből kiterjesztve, az IIS 6.0-nál a Microsoft biztonsági okokból szigorította a korlátozásokat. Figyelnünk kell a következőkre is:
1). Az IIS 6.0 alapértelmezett maximum 200 KB ASP POST adatot tartalmaz, és a korlát 100 KB űrlapmezőnként.
2). Az IIS 6.0 feltöltési fájlok alapértelmezett mérete 4MB.
3). Az IIS 6.0 alapértelmezett maximális kérésfejléce 16KB.
Ezek a korlátozások az IIS 6.0 előtt nem voltak elérhetők. [Lásd 5. hivatkozás]
Szóval a fenti 80K és 100K lehet, hogy csak az alapértelmezett értékek (megjegyzés: még nem erősítettem meg az IIS4 és IIS5 paramétereit), de ezeket biztosan be tudod állítani magadnak. Mivel ezeknek a paramétereknek az alapértelmezett értékei minden IIS verzióban eltérőek, kérjük, a részletekért lásd a vonatkozó IIS konfigurációs dokumentumot.
3. ASP-ben a szerver az Request.QueryString-et használja a GET request paraméter megszerzéséhez, a Request.Form segítségével pedig a POST request paraméter megszerzéséhez. JSP-ben használd az request.getParameter(\"XXXX\") kódot a megszerzéshez, bár a jsp-ben létezik request.getQueryString() metódus is, de ez nehezebb, például: küldj egy test.jsp?name=hyddd&password=hyddd-t, és request.getQueryString() segítségével megkapd a :name= hyddd&password=hyddd。 PHP-ben a GET és POST adatait _GET és _POST dollár értékkel lehet megszerezni, míg a GET és POST kérésekből _REQUEST dollárt is kaphatod. Érdemes megjegyezni, hogy rejtett veszélyek vannak abban, ha a kérés JSP-ben és a PHP-ben a $_REQUEST használatban van, amelyeket a következő cikkben összefoglalunk.
4.POST biztonságosabb, mint a GET. Megjegyzés: Az itt említett biztonság nem ugyanaz a fogalom, mint a fent említett "biztonság". Például, ha adatokat küld be a GET-en keresztül, a felhasználóneved és jelszavod tiszta szövegben jelenik meg az URL-en, mert (1) a bejelentkezési oldalt a böngésző gyorsíthatja el, (2) mások megtekintik a böngésző előzményeit, így mások megkaphatják a fiókodat és a jelszavadat hamisítási támadás.
Összefoglalva: a Get egy adatkérés a szerverről, míg a Post adat beküldésére vonatkozó kérés, a FORM-ban a Method alapértelmezettként "GET"-re van beállítva, lényegében a GET és POST csak különböző küldési mechanizmusok, nem egy másik küld el és küld egyet!
|
Közzétéve 2014. 12. 06. 10:54:55
|
|
|
Közzétéve 2014. 12. 07. 17:24:18
