HTTP definerer forskellige måder at interagere med serveren på, og der findes 4 grundlæggende metoder, nemlig GET, POST, PUT og DELETE. Det fulde navn på URL'en er en ressourcebeskriver, vi kan tænke på det således: en URL-adresse, den bruges til at beskrive en ressource på et netværk, og GET, POST, PUT, DELETE i HTTP svarer til de fire operationer: at tjekke, ændre, tilføje og slette denne ressource. På dette tidspunkt bør du have en generel forståelse, GET bruges generelt til at indhente/forespørge ressourceinformation, mens POST generelt bruges til at opdatere ressourceinformation.
1. Ifølge HTTP-specifikationen bruges GET til informationssøgning og skal være sikkert og idempotent.
(1). Den såkaldte sikkerhed betyder, at operationen bruges til at indhente information frem for at ændre den. Med andre ord bør GET-anmodninger generelt ikke have bivirkninger. Det vil sige, at den kun indhenter ressourceinformation, ligesom databaseforespørgsler, og vil ikke ændre, tilføje data eller påvirke ressourcens tilstand.
* Bemærk: Betydningen af sikkerhed her refererer kun til ikke-modificerede oplysninger.
(2). Idempotent betyder, at flere forespørgsler til samme URL skal returnere det samme resultat.
Men i praksis er de to ovenstående regler ikke så strenge. Eksempler på at citere andres artikler: For eksempel opdateres forsiden af en nyhedsside konstant. Selvom den anden anmodning returnerer en anden omgang nyheder, betragtes operationen stadig som sikker og idempotent, fordi den altid returnerer de aktuelle nyheder. Grundlæggende, hvis målet er, at når en bruger åbner et link, kan han være sikker på, at ressourcen ikke er blevet ændret fra hans synspunkt.
2. Ifølge HTTP-specifikationen repræsenterer POST en forespørgsel, der kan ændre en ressource på serveren. Fortsættende med at citere ovenstående eksempel: Stadig nyheder Tag hjemmesiden som eksempel, læsere bør poste deres egne kommentarer til nyhederne, fordi sidens ressourcer er anderledes efter kommentaren er indsendt, eller ressourcerne er ændret.
Ovenstående diskuterer groft nogle af principperne for GET og POST i HTTP-specifikationen. Dog følger mange ikke HTTP-specifikationen, når de rent faktisk gør det, hvilket kan føre til mange årsager til dette problem, såsom:
1. Mange bruger GET til at opdatere ressourcer, fordi de skal gå til FORM for at bruge POST, hvilket kan være lidt besværligt.
2. Operationen med at tilføje, slette, ændre og tjekke ressourcer kan faktisk gennemføres via GET/POST uden behov for at bruge PUT og DELETE.
3. En anden er, at tidlige udviklere af Web MVC-rammeværket ikke bevidst behandlede og designede URL'er som abstrakte ressourcer, så et alvorligt problem er, at det traditionelle Web MVC-rammeværk grundlæggende kun understøtter to HTTP-metoder, GET og POST, men ikke understøtter PUT og DELETE-metoder.
* En kort forklaring af MVC: MVC eksisterede oprindeligt i Desktop-programmet, M refererer til datamodellen, V refererer til brugergrænsefladen, og C refererer til controlleren. Formålet med at bruge MVC er at adskille implementeringskoden for M og V, så det samme program kan bruge forskellige repræsentationer.
De ovenstående tre punkter beskriver typisk den gamle stil (uden streng overholdelse af HTTP-specifikationen), med udviklingen af arkitekturen findes der nu REST (Representational State Transfer), en ny stil, der understøtter HTTP-specifikationen.
Efter at have talt om hovedproblemet, lad os se på forskellen mellem GET og POST ud fra overfladefænomenet:
1. Data fra GET-forespørgslen vil blive knyttet til URL'en (dvs. dataene placeres i HTTP-protokolheaderen), og ? Opdel URL'en og send dataene, og parametrene forbindes med &, for eksempel: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Hvis dataene er engelske bogstaver/tal, send det som det er; hvis det er et mellemrum, konverter det til +, hvis det er kinesiske/andre tegn, og krypter derefter strengen direkte med BASE64 for at få et eksempel som: %E4%BD%A0%E5%A5%BD, hvor XX i %XX er ASCII repræsenteret ved symbolet i hexadecimalt.
POST placerer de indsendte data i pakkens krop af HTTP-pakken.
2. "De maksimale data, der indsendes med GET-metoden, kan kun være 1024 bytes, teoretisk set er der ingen grænse for POST, og en stor mængde data kan overføres, op til 80KB i IIS4 og 100KB i IIS5"??!
Ovenstående sætning er omdirigeret fra andre artikler, faktisk er det forkert og unøjagtigt at sige dette:
(1). For det første, "dataene indsendt med GET-metoden kan højst være 1024 bytes", fordi GET indsender data via URL, så mængden af data, der kan indsendes af GET, er direkte relateret til URL'ens længde. Faktisk er der ingen øvre parametergrænse for URL'er, og HTTP-protokolspecifikationen begrænser ikke længden af URL'er. Denne begrænsning er en begrænsning pålagt af en specifik browser og server. IE's grænse for URL-længde er 2083 bytes (2K+35). For andre browsere som Netscape, Firefox osv. er der ingen teoretisk længdegrænse, og dens grænse afhænger af operativsystemets understøttelse.
Bemærk, at dette begrænser hele URL-længden, ikke kun længden på din parameterværdi. [Se Ref. 5]
(2). Teoretisk set har POST ingen størrelsesbegrænsning, og HTTP-protokolspecifikationen har ingen størrelsesbegrænsning, og det er unøjagtigt at sige, at "der er en størrelsesgrænse på 80K/100K for POST-data", og der er ingen grænse for POST-data, og det er serverens håndterers processorkraft, der spiller en begrænsende rolle.
For ASP-programmer har Request-objektet en datalængdegrænse på 100K, når hvert formularfelt skal behandles. Men med Request.BinaryRead findes der ingen sådan begrænsning.
Som en udvidelse af dette har Microsoft for IIS 6.0 øget restriktionerne af sikkerhedsmæssige årsager. Vi skal også være opmærksomme på:
1). IIS 6.0 er som standard maksimalt 200 KB ASP POST-data, og grænsen er 100 KB pr. formularfelt.
2). Standardstørrelsen på IIS 6.0 uploadfiler er 4MB.
3). IIS 6.0 har som standard en maksimal anmodningsheader på 16KB.
Disse begrænsninger var ikke tilgængelige før IIS 6.0. [Se Ref. 5]
Så ovenstående 80K og 100K kan bare være standardværdierne (bemærk: jeg har endnu ikke bekræftet parametrene for IIS4 og IIS5), men du kan helt sikkert selv sætte dem. Da standardværdierne for disse parametre er forskellige i hver version af IIS, henvises der til det relevante IIS-konfigurationsdokument for detaljer.
3. I ASP bruger serveren Request.QueryString til at hente GET-anmodningsparameteren og Request.Form til at hente POST-anmodningsparameteren. I JSP skal du bruge request.getParameter(\"XXXX\") til at hente den, selvom der også findes en request.getQueryString() metode i jsp, men den er mere besværlig at bruge, for eksempel: send en test.jsp?name=hyddd&password=hyddd, og brug request.getQueryString() for at få :name= Hyddd&password=hyddd。 I PHP kan du bruge $_GET og $_POST til at hente data fra henholdsvis GET og POST, mens $_REQUEST kan hente data fra både GET- og POST-anmodninger. Det er værd at bemærke, at der er skjulte farer ved at bruge request i JSP og $_REQUEST i PHP, hvilket vil blive opsummeret i en artikel næste gang.
4.POST er mere sikkert end GET. Bemærk: Den sikkerhed, der nævnes her, er ikke det samme koncept som den "sikkerhed", der nævnes i GET ovenfor. For eksempel, hvis du indsender data via GET, vil dit brugernavn og din adgangskode vises i klartekst på URL'en, fordi (1) login-siden kan være cachet af browseren, (2) andre vil se browserens historik, så andre kan få din konto og adgangskode Forfalskningsangreb.
For at opsummere er Get en anmodning om at anmode om data fra serveren, mens Post er en anmodning om at sende data til serveren; i FORM er metoden som standard "GET", i bund og grund er GET og POST bare forskellige afsendelsesmekanismer, ikke én tager og sender én!
|
Opslået på 06/12/2014 10.54.55
|
|
|
Opslået på 07/12/2014 17.24.18
