HTTP definerer ulike måter å samhandle med serveren på, og det finnes 4 grunnleggende metoder, nemlig GET, POST, PUT og DELETE. Det fulle navnet på URL er en ressursbeskriver, vi kan tenke på det slik: en URL-adresse, den brukes til å beskrive en ressurs på et nettverk, og GET, POST, PUT, DELETE i HTTP tilsvarer de fire operasjonene å sjekke, endre, legge til og slette denne ressursen. På dette tidspunktet bør du ha en generell forståelse, GET brukes vanligvis for å hente/spørre ressursinformasjon, mens POST vanligvis brukes til å oppdatere ressursinformasjon.
1. Ifølge HTTP-spesifikasjonen brukes GET til informasjonshenting og skal være sikkert og idempotent.
(1). Den såkalte sikkerheten betyr at operasjonen brukes til å innhente informasjon snarere enn å endre den. Med andre ord bør GET-forespørsler vanligvis ikke ha bivirkninger. Det vil si at den kun henter ressursinformasjon, akkurat som databasespørringer, og vil ikke endre, legge til data eller påvirke tilstanden til ressursen.
* Merk: Betydningen av sikkerhet her refererer kun til ikke-endret informasjon.
(2). idempotent betyr at flere forespørsler til samme URL skal returnere samme resultat.
Men i praksis er de to ovennevnte reglene ikke så strenge. Eksempler på å sitere andres artikler: For eksempel oppdateres forsiden av et nyhetsnettsted kontinuerlig. Selv om den andre forespørselen returnerer en annen gruppe nyheter, regnes operasjonen fortsatt som trygg og idempotent fordi den alltid returnerer de aktuelle nyhetene. Grunnleggende, hvis målet er at når en bruker åpner en lenke, kan han være trygg på at ressursen ikke har blitt endret fra hans synspunkt.
2. Ifølge HTTP-spesifikasjonen representerer POST en forespørsel som kan endre en ressurs på serveren. Fortsetter å sitere eksempelet ovenfor: Still nyheter Ta nettsiden som et eksempel, lesere bør poste egne kommentarer på nyheten, fordi sidens ressurser er forskjellige etter at kommentaren er sendt inn, eller at ressursene er endret.
Ovenstående diskuterer grovt noen av prinsippene for GET og POST i HTTP-spesifikasjonen. Mange følger imidlertid ikke HTTP-spesifikasjonen når de faktisk gjør det, noe som kan føre til mange årsaker til dette problemet, som for eksempel:
1. Mange bruker GET for å oppdatere ressurser fordi de må gå til FORM for å bruke POST, noe som kan være litt problematisk.
2. Operasjonen med å legge til, slette, endre og sjekke ressurser kan faktisk fullføres via GET/POST, uten behov for å bruke PUT og DELETE.
3. En annen er at tidlige utviklere av Web MVC-rammeverket ikke bevisst behandlet og designet URL-er som abstrakte ressurser, så et alvorlig problem er at det tradisjonelle Web MVC-rammeverket i praksis bare støtter to HTTP-metoder, GET og POST, men ikke PUT- og DELETE-metodene.
* En kort forklaring av MVC: MVC eksisterte opprinnelig i skrivebordsprogrammet, M refererer til datamodellen, V refererer til brukergrensesnittet, og C refererer til kontrolleren. Formålet med å bruke MVC er å skille implementasjonskoden til M og V, slik at det samme programmet kan bruke forskjellige representasjoner.
De tre punktene ovenfor beskriver vanligvis den gamle stilen (uten streng overholdelse av HTTP-spesifikasjonen), med utviklingen av arkitekturen finnes det nå REST (Representational State Transfer), en ny stil som støtter HTTP-spesifikasjonen.
Etter å ha snakket om hovedproblemet, la oss se på forskjellen mellom GET og POST ut fra overflatefenomenet:
1. Dataene fra GET-forespørselen vil bli knyttet til URL-en (det vil si at dataene plasseres i HTTP-protokollhodet), og ? Del URL-en og overfør dataene, og parameterne kobles sammen med &, for eksempel: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Hvis dataene er engelske bokstaver/tall, send det som det er, hvis det er et mellomrom, konverter det til +, hvis det er kinesiske/andre tegn, og krypter strengen direkte med BASE64 for å få et eksempel som: %E4%BD%A0%E5%A5%A5%BD, hvor XX i %XX er ASCII representert av symbolet i heksadesimalt.
POST plasserer de innsendte dataene i pakkekroppen til HTTP-pakken.
2. "Maksimal data sendt inn med GET-metoden kan bare være 1024 byte, teoretisk sett er det ingen grense for POST, og store mengder data kan overføres, opptil 80KB i IIS4 og 100KB i IIS5"??!
Setningen ovenfor er omdirigert fra andre artikler, faktisk er det feil og unøyaktig å si dette:
(1). Først og fremst, «dataene som sendes inn med GET-metoden kan bare være maksimalt 1024 byte», fordi GET sender inn data via URL, så mengden data som kan sendes inn av GET er direkte relatert til lengden på URL-en. Faktisk finnes det ingen øvre parametergrense for URL-er, og HTTP-protokollspesifikasjonen begrenser ikke lengden på URL-er. Denne begrensningen er en begrensning pålagt av en spesifikk nettleser og server. IEs grense for URL-lengde er 2083 byte (2K+35). For andre nettlesere som Netscape, Firefox osv. finnes det ingen teoretisk lengdegrense, og grensen avhenger av hvordan operativsystemet støtter.
Merk at dette begrenser hele URL-lengden, ikke bare lengden på parameterverdien. [Se Ref. 5]
(2). Teoretisk sett har POST ingen størrelsesgrense, og HTTP-protokollspesifikasjonen har ingen størrelsesgrense, og det er unøyaktig å si at «det er en størrelsesgrense på 80K/100K for POST-data», og det finnes ingen grense for POST-data, og det er serverens håndterers prosesseringskraft som spiller en begrensende rolle.
For ASP-programmer har Request-objektet en datalengdegrense på 100K når hvert skjemafelt behandles. Men med Request.BinaryRead finnes det ingen slik begrensning.
I tillegg til dette har Microsoft for IIS 6.0 økt restriksjonene av sikkerhetsmessige årsaker. Vi må også være oppmerksomme på:
1). IIS 6.0 har som standard maksimalt 200 KB ASP POST-data, og grensen er 100 KB per skjemafelt.
2). Standardstørrelsen på IIS 6.0-opplastingsfiler er 4MB.
3). IIS 6.0 har som standard en maksimal forespørselsheader på 16KB.
Disse begrensningene var ikke tilgjengelige før IIS 6.0. [Se Ref. 5]
Så de ovennevnte 80K og 100K kan bare være standardverdiene (merk: jeg har ikke bekreftet parameterne for IIS4 og IIS5 ennå), men du kan definitivt sette dem selv. Siden standardverdiene for disse parameterne er forskjellige i hver versjon av IIS, vennligst se det relevante IIS-konfigurasjonsdokumentet for detaljer.
3. I ASP bruker serveren Request.QueryString for å hente GET-forespørselsparameteren og Request.Form for å hente POST-forespørselsparameteren. I JSP, bruk request.getParameter(\"XXXX\") for å hente den, selv om det også finnes en request.getQueryString()-metode i jsp, men den er mer problematisk å bruke, for eksempel: send en test.jsp?name=hyddd&password=hyddd, og bruk request.getQueryString() for å få :name= hyddd&password=hyddd。 I PHP kan du bruke $_GET og $_POST for å hente data fra henholdsvis GET og POST, mens $_REQUEST kan hente data fra både GET- og POST-forespørsler. Det er verdt å merke seg at det finnes skjulte farer ved å bruke request i JSP og $_REQUEST i PHP, noe som vil bli oppsummert i en artikkel neste gang.
4.POST er sikrere enn GET. Merk: Sikkerheten som nevnes her er ikke det samme konseptet som "sikkerheten" nevnt i GET ovenfor. For eksempel, hvis du sender inn data via GET, vil brukernavn og passord vises i klartekst på URL-en, fordi (1) innloggingssiden kan være bufret av nettleseren, (2) andre vil se nettleserens historikk, slik at andre kan få tak i kontoen og passordet ditt Forfalskningsangrep.
For å oppsummere, Get er en forespørsel om å be om data fra serveren, mens Post er en forespørsel om å sende data til serveren, i FORM er metoden som standard «GET», i bunn og grunn er GET og POST bare forskjellige sendemekanismer, ikke én tar og sender én!
|
Publisert på 06.12.2014 10:54:55
|
|
|
Publisert på 07.12.2014 17:24:18
