HTTP definuje různé způsoby interakce se serverem a existují 4 základní metody, a to GET, POST, PUT a DELETE. Celý název URL je popis zdroje, můžeme si ho představit takto: URL adresa, používá se k popisu zdroje v síti a GET, POST, PUT, DELETE v HTTP odpovídá čtyřem operacím kontroly, úpravy, přidávání a mazání tohoto zdroje. V této fázi byste měli mít obecné pochopení, že GET se obecně používá k získávání/dotazování informací o zdrojích, zatímco POST se obecně používá k aktualizaci informací o zdrojích.
1. Podle HTTP specifikace se GET používá pro vyhledávání informací a měl by být bezpečný a idempotentní.
(1). Takzvaná bezpečnost znamená, že operace slouží k získání informací, nikoli k jejich úpravě. Jinými slovy, požadavky na GET by obecně neměly mít vedlejší účinky. To znamená, že získává pouze informace o zdroji, stejně jako dotaz do databáze, a nebude měnit, přidávat data ani ovlivňovat stav zdroje.
* Poznámka: Význam bezpečnosti zde odkazuje pouze na nemodifikované informace.
(2). idempotent znamená, že více požadavků na stejnou URL by mělo vrátit stejný výsledek.
V praktickém použití však výše uvedené dvě předpisy nejsou tak přísné. Příklady citací cizích článků: Například úvodní stránka zpravodajského webu je neustále aktualizována. Zatímco druhý požadavek vrací jinou várku zpráv, operace je stále považována za bezpečnou a idempotentní, protože vždy vrací aktuální zprávy. Základně, pokud je cílem uživatel, aby při otevření odkazu mohl mít jistotu, že zdroj z jeho pohledu nebyl změněn.
2. Podle specifikace HTTP představuje POST požadavek, který může upravit zdroj na serveru. Pokračujíc v citaci výše uvedeného příkladu: Still news Vezměte si například web, čtenáři by měli zveřejňovat své vlastní komentáře k novinkám, protože zdroje webu se po odeslání komentáře nebo úpravě změní.
Výše uvedené přibližně pojednává o některých principech GET a POST ve specifikaci HTTP. Mnoho lidí však při skutečném provádění nedodržuje specifikaci HTTP, což může vést k mnoha důvodům tohoto problému, například:
1. Mnoho lidí používá GET k aktualizaci zdrojů, protože musí jít do FORM, aby použili POST, což bude trochu problematické.
2. Operace přidávání, mazání, úpravy a kontroly zdrojů může být skutečně dokončena pomocí GET/POST, bez nutnosti používat PUT a DELETE.
3. Další je, že raní návrháři webových MVC frameworků vědomě nepovažovali a nenavrhovali URL jako abstraktní zdroje, takže vážným problémem je, že tradiční Web MVC framework v podstatě podporuje pouze dvě HTTP metody, GET a POST, ale nepodporuje metody PUT a DELETE.
* Stručné vysvětlení MVC: MVC původně existovalo v programu Desktop, M označuje datový model, V uživatelské rozhraní a C řadiče. Účelem použití MVC je oddělit implementační kód M a V, aby stejný program mohl používat různé reprezentace.
Výše uvedené 3 body obvykle popisují starý styl (bez přísného dodržování HTTP specifikace), s vývojem architektury nyní existuje REST (Representational State Transfer), nový styl podporující HTTP specifikaci.
Po diskusi o hlavním problému se podívejme na rozdíl mezi GET a POST z povrchového jevu:
1. Data požadavku GET budou připojena k URL (tedy data jsou umístěna do hlavičky HTTP protokolu) a ? Rozdělte URL a odesílejte data, parametry jsou propojeny pomocí &, například: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Pokud jsou data anglická písmena/čísla, pošlete je tak, jak jsou, pokud je to mezera, převeďte je na +, pokud jsou to čínské/jiné znaky, pak přímo zašifrujte řetězec pomocí BASE64, abyste získali vzorek například: %E4%BD%A0%E5%A5%BD, kde XX v %XX je ASCII reprezentované symbolem v hexadecimálním formátu.
POST umístí odeslaná data do těla paketu HTTP paketu.
2. "Maximální počet dat odeslaných metodou GET může být pouze 1024 bajtů, teoreticky neexistuje limit pro POST a lze přenést velké množství dat, až 80KB v IIS4 a 100KB v IIS5"??!
Výše uvedená věta je přesměrována z jiných článků, ve skutečnosti je špatné a nepřesné říkat toto:
(1). Za prvé, "data odeslaná metodou GET mohou mít maximálně 1024 bajtů", protože GET odesílá data přes URL, takže množství dat, která může GET odevzdat, je přímo spojeno s délkou URL. Ve skutečnosti neexistuje žádný horní limit parametrů pro URL a specifikace protokolu HTTP neomezuje délku URL. Toto omezení je omezení uvalené konkrétním prohlížečem a serverem. Limit délky URL IE je 2083 bajtů (2K+35). U jiných prohlížečů jako Netscape, FireFox atd. neexistuje teoretické omezení délky a jeho limit závisí na podpoře operačního systému.
Všimněte si, že to omezuje celou délku URL, nejen délku parametru, hodnoty dat. [Viz ref. 5]
(2). Teoreticky POST nemá limit velikosti a specifikace protokolu HTTP nemá limit velikosti, a není přesné říci, že "existuje limit velikosti 80K/100K pro POST data", neexistuje žádný limit pro POST data, a omezující roli hraje výpočetní výkon handleru serveru.
U ASP programů má objekt Request limit délky dat 100K při zpracování každého formulářového pole. Ale u Request.BinaryRead takové omezení není.
Na základě toho Microsoft pro IIS 6.0 zvýšil omezení z bezpečnostních důvodů. Musíme také věnovat pozornost:
1). IIS 6.0 ve výchozím nastavení umožňuje maximálně 200 KB dat ASP POST a limit je 100 KB na pole formuláře. 2). Výchozí velikost uploadových souborů IIS 6.0 je 4MB. 3). IIS 6.0 má výchozí maximální záhlavku požadavku 16KB. Tato omezení nebyla před IIS 6.0 dostupná. [Viz ref. 5]
Takže výše uvedené 80K a 100K mohou být jen výchozí hodnoty (poznámka: parametry IIS4 a IIS5 jsem ještě nepotvrdil), ale určitě si je můžete nastavit sami. Protože výchozí hodnoty těchto parametrů se v každé verzi IIS liší, podívejte se prosím na příslušný konfigurační dokument IIS pro podrobnosti.
3. V ASP server používá Request.QueryString k získání parametru GET požadavku a Request.Form k získání parametru POST požadavku. V JSP použijte request.getParameter(\"XXXX\") k jeho získání, i když existuje také metoda request.getQueryString() v jsp, ale je obtížnější ji použít, například: pošlete test.jsp?name=hyddd&password=hyddd, a použijte request.getQueryString() pro :name= hyddd&password=hyddd。 V PHP můžete použít _GET $ a _POST $ k získání dat z GET a POST, zatímco $_REQUEST lze získat data jak z požadavků GET, tak POST. Stojí za zmínku, že používání request v JSP a $_REQUEST v PHP má skrytá rizika, což bude shrnuto v příštím článku.
4.POST je bezpečnější než GET. Poznámka: Bezpečnost zmíněná zde není stejným konceptem jako "bezpečnost" uvedená v GET výše. Například pokud odešlete data přes GET, vaše uživatelské jméno a heslo se zobrazí v čistém textu na URL, protože (1) přihlašovací stránka může být prohlížečem uložena do cache, (2) ostatní budou sledovat historii prohlížeče, takže ostatní mohou získat váš účet a heslo Útok paděláním.
Shrnuto, Get je požadavek na požadavek na data ze serveru, zatímco Post je požadavek na odeslání dat na server, ve FORM je metoda výchozí nastavená na "GET", v podstatě jsou GET a POST jen různé mechanismy odesílání, ne jeden přijímá a odesílá jeden jeden z nich!
|