HTTP določa različne načine interakcije s strežnikom in obstajajo 4 osnovne metode, in sicer GET, POST, PUT in DELETE. Polno ime URL-ja je opis vira, lahko si ga predstavljamo takole: URL naslov, uporablja se za opis vira v omrežju, in GET, POST, PUT, DELETE v HTTP ustreza štirim operacijam: preverjanju, spreminjanju, dodajanju in brisanju tega vira. Na tej točki bi morali imeti splošno razumevanje, da se GET običajno uporablja za pridobivanje in poizvedovanje informacij o virih, medtem ko se POST običajno uporablja za posodabljanje informacij o virih.
1. Po HTTP specifikaciji se GET uporablja za pridobivanje informacij in mora biti varen ter idempotenten.
(1). Tako imenovana varnost pomeni, da se operacija uporablja za pridobivanje informacij in ne za njihovo spreminjanje. Z drugimi besedami, zahteve za GET običajno ne bi smele imeti stranskih učinkov. To pomeni, da pridobiva le informacije o virih, podobno kot poizvedba v bazi podatkov, in ne spreminja, dodaja podatkov ali vpliva na stanje vira.
* Opomba: Pomen varnosti tukaj se nanaša le na nespremenjene informacije.
(2). idempotentno pomeni, da več zahtevkov na isti URL vrne enak rezultat.
Vendar pa v praktični uporabi zgornji dve uredbi nista tako strogi. Primeri citiranja člankov drugih ljudi: Na primer, naslovna stran novičarskega portala se nenehno posodablja. Čeprav druga zahteva vrne drugačen paket novic, je operacija še vedno varna in idempotentna, saj vedno vrne aktualne novice. Temeljno, če je cilj, da je uporabnik, ko odpre povezavo, lahko prepričan, da vir ni bil spremenjen z njegovega vidika.
2. Po HTTP specifikaciji POST predstavlja zahtevo, ki lahko spremeni vir na strežniku. Če nadaljujemo s citiranjem zgornjega primera: Še vedno novice Vzemimo za primer spletno stran, bralci naj objavijo svoje komentarje o novicah, saj so viri na strani drugačni po oddaji komentarja ali po spremembi virov.
Zgornje približno obravnava nekatere principe GET in POST v HTTP specifikaciji. Vendar pa veliko ljudi ne upošteva HTTP specifikacije, ko to dejansko izvajajo, kar lahko povzroči več razlogov za to težavo, kot so:
1. Veliko ljudi uporablja GET za posodabljanje virov, ker morajo za uporabo POST iti v FORM, kar bo nekoliko problematično.
2. Postopek dodajanja, brisanja, spreminjanja in preverjanja virov je dejansko mogoče izvesti preko GET/POST, brez potrebe po uporabi PUT in DELETE.
3. Druga je, da zgodnji oblikovalci Web MVC ogrodij niso zavestno obravnavali in oblikovali URL-jev kot abstraktnih virov, zato je resen problem, da tradicionalni Web MVC okvir v bistvu podpira le dve HTTP metodi, GET in POST, ne pa pa metod PUT in DELETE.
* Kratka razlaga MVC: MVC je prvotno obstajal v namiznem programu, M se nanaša na podatkovni model, V na uporabniški vmesnik, C pa na krmilnik. Namen uporabe MVC je ločiti implementacijsko kodo M in V, da lahko isti program uporablja različne predstavitve.
Zgornje tri točke običajno opisujejo stari slog (brez strogega upoštevanja HTTP specifikacije); z razvojem arhitekture je zdaj na voljo REST (Representational State Transfer), nov slog, ki podpira HTTP specifikacijo.
Po razpravi o glavnem problemu si poglejmo razliko med GET in POST glede na površinski pojav:
1. Podatki zahteve GET bodo priloženi URL-ju (to pomeni, da so podatki vključeni v HTTP protokolno glavo), in ? Razdeli URL in prenesi podatke, parametri pa so povezani z &, na primer: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Če so podatki angleške črke/številke, jih pošljite takšne, kot so, če so presledek, jih pretvorite v +, če so kitajski/drugi znaki, nato neposredno šifrirajte niz z BASE64, da dobite vzorec, kot je: %E4%BD%A0%E5%A5%BD, kjer je XX v %XX ASCII, ki ga simbol predstavlja v šestnajstiškem sistemu.
POST postavi oddane podatke v telo paketa HTTP paketa.
2. "Največje število podatkov, ki jih pošlje metoda GET, je lahko le 1024 bajtov, teoretično ni omejitve za POST, in prenesemo veliko količino podatkov, do 80KB v IIS4 in 100KB v IIS5"??!
Zgornji stavek je preusmerjen iz drugih člankov, pravzaprav je napačno in netočno reči to:
(1). Najprej, "podatki, ki jih oddaja metoda GET, lahko obsegajo največ 1024 bajtov", ker GET pošilja podatke prek URL-ja, zato je količina podatkov, ki jih lahko GET pošlje, neposredno povezana z dolžino URL-ja. Pravzaprav ni zgornje omejitve parametrov za URL-je, specifikacija protokola HTTP pa ne omejuje dolžine URL-jev. Ta omejitev je določena s strani določenega brskalnika in strežnika. Omejitev dolžine URL-ja pri IE je 2083 bajtov (2K+35). Za druge brskalnike, kot so Netscape, Firefox itd., ni teoretične omejitve dolžine, njena omejitev pa je odvisna od podpore operacijskega sistema.
Upoštevajte, da to omejuje celotno dolžino URL-ja, ne le dolžino podatkov o vrednosti parametra. [Glej Ref. 5]
(2). Teoretično POST nima omejitve velikosti, specifikacija protokola HTTP nima omejitve velikosti, in ni natančno trditi, da "obstaja omejitev velikosti 80K/100K za POST podatke", ni omejitve za POST podatke, omejevalna vloga pa ima procesorska moč strežnika handlerja.
Pri ASP programih ima objekt Request omejitev dolžine podatkov 100K pri obdelavi vsakega polja obrazca. Pri Request.BinaryRead pa takšne omejitve ni.
Na podlagi tega je Microsoft za IIS 6.0 zaradi varnostnih razlogov povečal omejitve. Prav tako moramo biti pozorni na:
1). IIS 6.0 privzeto omogoča največ 200 KB podatkov ASP POST, omejitev pa je 100 KB na polje obrazca.
2). Privzeta velikost datotek za nalaganje v IIS 6.0 je 4MB.
3). IIS 6.0 privzeto uporablja največjo glavo zahteve 16KB.
Te omejitve pred IIS 6.0 niso bile na voljo. [Glej Ref. 5]
Torej sta zgornji 80K in 100K morda samo privzeti vrednosti (opomba: parametrov IIS4 in IIS5 še nisem potrdil), vendar ju lahko zagotovo nastavite sami. Ker so privzete vrednosti teh parametrov v vsaki različici IIS različne, si za podrobnosti oglejte ustrezni konfiguracijski dokument IIS.
3. V ASP strežnik uporablja Request.QueryString za pridobitev parametra zahteve GET in Request.Form za pridobitev parametra zahteve POST. V JSP uporabite request.getParameter(\"XXXX\") za pridobitev tega, čeprav obstaja tudi metoda request.getQueryString() v jsp, vendar je bolj zahtevna za uporabo, na primer: pošljite test.jsp?name=hyddd&password=hyddd, uporabite request.getQueryString() za :name= hyddd&password=hyddd。 V PHP-ju lahko uporabite $_GET in $_POST za pridobivanje podatkov iz GET oziroma POST, medtem ko lahko $_REQUEST pridobi podatke tako iz zahtev GET kot POST. Vredno je omeniti, da obstajajo skrite nevarnosti pri uporabi zahtevkov v JSP in _REQUEST dolarjev v PHP, kar bo povzeto v naslednjem članku.
4.POST je bolj varen kot GET. Opomba: Vrednost, omenjena tukaj, ni enak konceptu kot "varnost", omenjena v zgornjem GET-u. Na primer, če podatke vnesete prek GET-a, se bo vaše uporabniško ime in geslo prikazalo v navadnem besedilu na URL-ju, ker (1) lahko brskalnik predpomnilnik shrani prijavno stran, (2) drugi bodo pregledali zgodovino brskalnika, tako da lahko drugi dobijo vaš račun in geslo Napad s ponarejevanjem.
Za povzetek: Get je zahteva za zahtevo podatkov od strežnika, medtem ko je Post zahteva za oddajo podatkov strežniku, v FORM je Method privzeto "GET", v bistvu sta GET in POST le različna mehanizma pošiljanja, ne da bi eden sprejel in poslal enega!
|
Objavljeno na 6. 12. 2014 10:54:55
|
|
|
Objavljeno na 7. 12. 2014 17:24:18
