HTTP definierar olika sätt att interagera med servern, och det finns fyra grundläggande metoder, nämligen GET, POST, PUT och DELETE. Det fullständiga namnet på URL:en är en resursbeskrivare, vi kan tänka på det så här: en URL-adress, den används för att beskriva en resurs i ett nätverk, och GET, POST, PUT, DELETE i HTTP motsvarar de fyra operationerna att kontrollera, ändra, lägga till och ta bort denna resurs. Vid det här laget bör du ha en allmän förståelse, GET används vanligtvis för att erhålla eller söka resursinformation, medan POST oftast används för att uppdatera resursinformation.
1. Enligt HTTP-specifikationen används GET för informationshämtning och ska vara säkert och idempotent.
(1). Den så kallade säkerheten innebär att operationen används för att erhålla information snarare än att ändra den. Med andra ord bör GET-förfrågningar generellt inte ha några bieffekter. Det vill säga, den hämtar endast resursinformation, precis som databasfrågor, och kommer inte att ändra, lägga till data eller påverka resursens tillstånd.
* Not: Betydelsen av säkerhet här avser endast icke-modifierad information.
(2). idempotent betyder att flera förfrågningar till samma URL ska returnera samma resultat.
I praktiken är dock ovanstående två regler inte lika strikta. Exempel på att citera andras artiklar: Till exempel uppdateras förstasidan på en nyhetssida ständigt. Även om den andra förfrågan returnerar en annan mängd nyheter, anses operationen ändå vara säker och idempotent eftersom den alltid returnerar aktuella nyheter. I grunden, om målet är att när en användare öppnar en länk kan han vara säker på att resursen inte har ändrats ur hans synvinkel.
2. Enligt HTTP-specifikationen representerar POST en begäran som kan modifiera en resurs på servern. Fortsätter att citera exemplet ovan: Still news Ta webbplatsen som exempel, läsare bör posta egna kommentarer på nyheterna, eftersom sajtens resurser är annorlunda efter att kommentaren skickats in eller att resurserna har ändrats.
Ovanstående diskuterar ungefär några av principerna för GET och POST i HTTP-specifikationen. Många följer dock inte HTTP-specifikationen när de faktiskt gör det, vilket kan leda till många orsaker till detta problem, såsom:
1. Många använder GET för att uppdatera resurser eftersom de måste gå till FORM för att använda POST, vilket kan vara lite besvärligt.
2. Operationen att lägga till, radera, modifiera och kontrollera resurser kan faktiskt slutföras via GET/POST, utan att behöva använda PUT och DELETE.
3. En annan är att tidiga webb-MVC-ramverksdesigners inte medvetet behandlade och designade URL:er som abstrakta resurser, så ett allvarligt problem är att det traditionella Web MVC-ramverket i princip bara stöder två HTTP-metoder, GET och POST, men inte PUT- och DELETE-metoder.
* En kort förklaring av MVC: MVC fanns ursprungligen i Desktop-programmet, M avser datamodellen, V avser användargränssnittet och C avser kontrollern. Syftet med att använda MVC är att separera implementationskoden för M och V, så att samma program kan använda olika representationer.
De tre punkterna ovan beskriver vanligtvis den gamla stilen (utan strikt efterlevnad av HTTP-specifikationen), med utvecklingen av arkitekturen finns nu REST (Representational State Transfer), en ny stil som stöder HTTP-specifikationen.
Efter att ha pratat om huvudproblemet, låt oss titta på skillnaden mellan GET och POST utifrån ytfenomenet:
1. Datan från GET-förfrågan kommer att kopplas till URL:en (det vill säga datan placeras i HTTP-protokollets header), och ? Dela upp URL:en och överför datan, och parametrarna kopplas ihop med &, till exempel: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Om datan är engelska bokstäver/siffror, skicka det som det är, om det är ett mellanslag, konvertera det till +, om det är kinesiska/andra tecken, och kryptera sedan strängen direkt med BASE64 för att få ett exempel som: %E4%BD%A0%E5%A5%BD, där XX i %XX är ASCII representerat av symbolen i hexadecimal.
POST placerar den inskickade datan i paketets kropp för HTTP-paketet.
2. "Den maximala datan som skickas med GET-metoden kan endast vara 1024 byte, teoretiskt finns det ingen gräns för POST, och en stor mängd data kan överföras, upp till 80KB i IIS4 och 100KB i IIS5"??!
Ovanstående mening är omdirigerad från andra artiklar, faktiskt är det fel och felaktigt att säga detta:
(1). För det första kan "data som skickas in med GET-metoden endast vara högst 1024 byte", eftersom GET skickar in data via URL, så mängden data som kan skickas in av GET är direkt relaterad till URL:ens längd. Faktum är att det inte finns någon övre parametergräns för URL:er, och HTTP-protokollets specifikation begränsar inte längden på URL:er. Denna begränsning är en begränsning som påtvingas av en specifik webbläsare och server. IE:s gräns för URL-längd är 2083 byte (2K+35). För andra webbläsare som Netscape, Firefox med flera finns det ingen teoretisk längdgräns, och dess gräns beror på operativsystemets stöd.
Observera att detta begränsar hela URL-längden, inte bara din parametervärdesdata. [Se Ref. 5]
(2). Teoretiskt sett har POST ingen storleksgräns, och HTTP-protokollspecifikationen har ingen storleksgräns, och det är felaktigt att säga att "det finns en storleksgräns på 80K/100K för POST-data", och det finns ingen gräns för POST-data, och det är processorkraften hos serverns hanterare som spelar en begränsande roll.
För ASP-program har Request-objektet en datalängdsgräns på 100K när varje formulärfält behandlas. Men med Request.BinaryRead finns ingen sådan begränsning.
Utöver detta har Microsoft för IIS 6.0 ökat restriktionerna av säkerhetsskäl. Vi måste också uppmärksamma på:
1). IIS 6.0 är som standard maximalt 200 KB ASP POST-data, och gränsen är 100 KB per formulärfält.
2). Standardstorleken på IIS 6.0-uppladdningsfiler är 4 MB.
3). IIS 6.0 har som standard en maximal begäran på 16KB.
Dessa begränsningar fanns inte före IIS 6.0. [Se Ref. 5]
Så ovanstående 80K och 100K kan bara vara standardvärdena (obs: jag har inte bekräftat parametrarna för IIS4 och IIS5 än), men du kan definitivt ställa in dem själv. Eftersom standardvärdena för dessa parametrar skiljer sig åt i varje version av IIS, vänligen se det relevanta IIS-konfigurationsdokumentet för detaljer.
3. I ASP använder servern Request.QueryString för att hämta GET-begäranparametern och Request.Form för att hämta POST-begäranparametern. I JSP använder du request.getParameter(\"XXXX\") för att hämta den, även om det också finns en request.getQueryString()-metod i jsp, men den är mer besvärlig att använda, till exempel: skicka en test.jsp?name=hyddd&password=hyddd, och använd request.getQueryString() för att få :name= hyddd&password=hyddd。 I PHP kan du använda _GET och _POST dollar för att hämta data från GET respektive POST, medan _REQUEST dollar kan hämta data från både GET och POST-förfrågningar. Det är värt att notera att det finns dolda faror med att använda request i JSP och $_REQUEST i PHP, vilket kommer att sammanfattas i en artikel nästa gång.
4.POST är säkrare än GET. Notera: Den säkerhet som nämns här är inte samma koncept som "säkerheten" som nämns i GET ovan. Till exempel, om du skickar in data via GET, kommer ditt användarnamn och lösenord att visas i klartext på URL:en, eftersom (1) inloggningssidan kan vara cachad av webbläsaren, (2) andra kommer att se webbläsarens historik, så att andra kan få ditt konto och lösenord Förfalskningsattack.
Sammanfattningsvis är Get en begäran om att begära data från servern, medan Post är en begäran om att skicka data till servern, i FORM är Method som standard "GET", i princip är GET och POST bara olika sändningsmekanismer, inte en tar och skickar en!
|
Publicerad på 2014-12-06 10:54:55
|
|
|
Publicerad på 2014-12-07 17:24:18
