HTTP määratleb erinevad viisid serveriga suhtlemiseks ning on 4 põhilist meetodit: GET, POST, PUT ja DELETE. URL-i täisnimi on ressursi kirjeldaja, seda võib mõelda nii: URL-aadress, mida kasutatakse ressursi kirjeldamiseks võrgus, ja GET, POST, PUT, DELETE HTTP-s vastab neljale toimingule – selle ressursi kontrollimine, muutmine, lisamine ja kustutamine. Praeguseks peaks sul olema üldine arusaam – GET-i kasutatakse tavaliselt ressursiinfo hankimiseks/pärimiseks, samas kui POST-i kasutatakse ressursiinfo uuendamiseks.
1. HTTP spetsifikatsiooni kohaselt kasutatakse GET-i info otsimiseks ning see peaks olema turvaline ja idempotentne.
(1). Niinimetatud turvalisus tähendab, et operatsiooni kasutatakse info hankimiseks, mitte muutmiseks. Teisisõnu, GET-taotlustel ei tohiks üldjuhul olla kõrvalmõjusid. See tähendab, et see saab ainult ressursiteavet, nagu andmebaasi päring, ega muuda ega lisa andmeid ega mõjuta ressursi olekut.
* Märkus: Turvalisuse tähendus viitab siin ainult muutmata teabele.
(2). idempotent tähendab, et mitu päringut samale URL-ile peaksid andma sama tulemuse.
Praktilises rakenduses ei ole ülaltoodud kaks regulatsiooni siiski nii ranged. Näited teiste inimeste artiklite tsiteerimisest: Näiteks uudisteportaali esilehte uuendatakse pidevalt. Kuigi teine päring toob teise uudistepartii, peetakse operatsiooni siiski turvaliseks ja idempotentseks, sest see tagastab alati ajakohased uudised. Põhimõtteliselt, kui eesmärk on see, et kasutaja avab lingi, võib ta olla kindel, et ressurss pole tema vaatenurgast muudetud.
2. HTTP spetsifikatsiooni kohaselt esindab POST päringut, mis võib muuta serveri ressurssi. Jätkates eelneva näite tsiteerimist: Still uudised Võtame näiteks veebilehe, lugejad peaksid postitama oma kommentaarid uudistele, sest saidi ressursid muutuvad pärast kommentaari esitamist või ressursside muutmist.
Ülaltoodud käsitleb ligikaudu mõningaid GET ja POST põhimõtteid HTTP spetsifikatsioonis. Kuid paljud inimesed ei järgi HTTP spetsifikatsiooni, mis võib põhjustada mitmeid põhjuseid, näiteks:
1. Paljud inimesed kasutavad GET-i ressursside uuendamiseks, sest nad peavad minema FORM-i, et POST-i kasutada, mis võib olla veidi tülikas.
2. Ressursside lisamise, kustutamise, muutmise ja kontrollimise toimingud on tegelikult teostatavad GET/POST abil, ilma et oleks vaja kasutada PUT ja DELETE.
3. Teine on see, et varased Web MVC raamistiku disainerid ei käsitlenud ega kujundanud URL-e teadlikult abstraktsete ressurssidena, seega on tõsine probleem see, et traditsiooniline Web MVC raamistik toetab põhimõtteliselt ainult kahte HTTP meetodit, GET ja POST, kuid ei toeta PUT ja DELETE meetodeid.
* Lühike selgitus MVC kohta: MVC eksisteeris algselt töölauaprogrammis, M viitab andmemudelile, V viitab kasutajaliidesele ja C tähendab kontrollerit. MVC kasutamise eesmärk on eraldada M ja V rakenduskood, et sama programm saaks kasutada erinevaid esitusi.
Ülaltoodud 3 punkti kirjeldavad tavaliselt vana stiili (ilma rangelt HTTP spetsifikatsiooni järgimiseta), arhitektuuri arenguga on nüüd olemas REST (Representatsioonilise oleku ülekandmine), uus stiil, mis toetab HTTP spetsifikatsiooni.
Pärast põhiprobleemi arutamist vaatame GET ja POST erinevust pinnafenomenist:
1. GET-päringu andmed lisatakse URL-ile (ehk andmed paigutatakse HTTP protokolli päisse) ja ? Jaga URL ja edasta andmed, ning parameetrid on ühendatud &-ga, näiteks: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Kui andmed on ingliskeelsed tähed/numbrid, saada see nii, nagu see on, kui see on tühik, teisenda see +-ks, kui see on hiina/muud märgid, siis krüpteeri string otse BASE64-ga, et saada näidis näiteks: %E4%BD%A0%E5%A5%BD, kus XX %XX-s on ASCII, mida tähistab sümbol kuueteistkümnendsüsteemis.
POST paigutab esitatud andmed HTTP paketi kehasse.
2. "GET meetodi maksimaalne andmemaht võib olla ainult 1024 baiti, teoreetiliselt pole POST-il piirangut ning võib edastada suurt hulka andmeid, kuni 80KB IIS4-s ja 100KB IIS5-s"??!
Ülaltoodud lause on suunatud teistest artiklitest, tegelikult on vale ja ebatäpne öelda nii:
(1). Esiteks, "GET meetodiga esitatud andmed võivad olla maksimaalselt 1024 baiti", sest GET esitab andmeid URL-i kaudu, seega on GET-i poolt esitatavate andmete hulk otseselt seotud URL-i pikkusega. Tegelikult puudub URL-ide ülemine parameetrite piirang ning HTTP protokolli spetsifikatsioon ei piira URL-ide pikkust. See piirang on piirang, mille kehtestab konkreetne brauser ja server. IE URL-i pikkuse piirang on 2083 baiti (2K+35). Teistel brauseritel nagu Netscape, FireFox jne puudub teoreetiline pikkuse piirang ning selle piirang sõltub operatsioonisüsteemi toest.
Pane tähele, et see piirab kogu URL-i pikkust, mitte ainult sinu parameetri väärtuse andmepikkust. [Vaata viide 5]
(2). Teoreetiliselt ei ole POST-il suurusepiirangut ja HTTP protokolli spetsifikatsioonil puudub suuruspiirang, ning on ebatäpne öelda, et "POST-andmetel on suurusepiirang 80K/100K", POST-andmetel pole piirangut ning piiravat rolli mängib serveri haldaja töötlemisvõimsus.
ASP programmide puhul on Request objektil iga vormivälja töötlemisel 100K andmepikkuse piirang. Aga Request.BinaryRead puhul sellist piirangut ei ole.
Sellest lähtuvalt on Microsoft IIS 6.0 puhul turvalisuse kaalutlustel piiranguid karmistanud. Samuti peame tähelepanu pöörama:
1). IIS 6.0 vaikimisi kasutab maksimaalselt 200 KB ASP POST andmeid ning piirang on 100 KB vormivälja kohta.
2). IIS 6.0 üleslaadimisfailide vaikimisi suurus on 4MB.
3). IIS 6.0 vaikimisi kasutab maksimaalset päringupäist 16KB.
Need piirangud puudusid enne IIS 6.0 versiooni. [Vaata viide 5]
Seega võivad ülaltoodud 80K ja 100K olla lihtsalt vaikimisi väärtused (märkus: ma pole veel IIS4 ja IIS5 parameetreid kinnitanud), aga saad need kindlasti ise seadistada. Kuna nende parameetrite vaikimisi väärtused on igas IIS-i versioonis erinevad, vaata täpsemalt vastavat IIS-i konfiguratsioonidokumenti.
3. ASP-s kasutab server GET päringu parameetri saamiseks Request.QueryStringi ja POST päringuparameetri saamiseks Request.Form'i. JSP-s kasuta request.getParameter(\"XXXX\") selle saamiseks, kuigi jsp-s on olemas ka request.getQueryString() meetod, kuid selle kasutamine on keerulisem, näiteks: saada test.jsp?name=hyddd&password=hyddd ja kasutada request.getQueryString(), et saada :name= hyddd&password=hyddd。 PHP-s saad kasutada $_GET ja $_POST, et saada andmeid vastavalt GET-ist ja POST-ist, samas kui $_REQUEST saab andmeid nii GET kui POST päringutest. Tasub märkida, et JSP-s päringu kasutamisel ja PHP-s $_REQUEST kasutamisel on varjatud ohud, mida järgmisel korral artiklis kokku võtan.
4.POST on turvalisem kui GET. Märkus: Siin mainitud turvalisus ei ole sama mõiste kui ülaltoodud GET-is mainitud "turvalisus". Näiteks, kui esitad andmeid GET kaudu, kuvatakse sinu kasutajanimi ja parool URL-il selgesõnalisena, sest (1) brauser võib sisselogimisleht vahemällu salvestada, (2) teised vaatavad brauseri ajalugu, et teised saaksid sinu konto ja parooli võltsimisrünnak.
Kokkuvõtteks: Get on taotlus andmete taotlemiseks serverist, samas kui Post on taotlus andmete esitamiseks serverile, FORM-is on meetod vaikimisi "GET", sisuliselt on GET ja POST lihtsalt erinevad saatmismehhanismid, mitte üks neist ei võta ega saada!
|
Postitatud 06.12.2014 10:54:55
|
|
|
Postitatud 07.12.2014 17:24:18
