GET vs. POST

HTTP POST forespørsler leverer ytterligere data fra klienten (nettleseren) til serveren i meldingslegemet. I motsetning, FÅ forespørsler inkluderer alle nødvendige data i nettadressen. Skjemaer i HTML kan bruke begge metoder ved å spesifisere method = "post" eller method = "GET" (standard) i element. Metoden spesifisert bestemmer hvordan skjemadata sendes til serveren. Når metoden er GET, er alle formdata kodet inn i nettadressen, vedlagt til handling URL som forespørselsstrengsparametere. Med POST vises skjemadata i meldingslegemet til HTTP-forespørselen.

Sammenligningstabell

GET versus POST sammenligning diagram

FÅ	POST

Historie	Parametrene forblir i nettleserloggen fordi de er en del av nettadressen	Parametrene lagres ikke i nettleserloggen.
bokmerket	Kan bokmerkes.	Kan ikke bokmerkes.
TILBAKE-knapp / sende inn på nytt	GET-forespørsler utføres på nytt, men kan ikke sendes tilbake til serveren hvis HTML-en er lagret i nettleserens cache.	Nettleseren varsler vanligvis brukeren om at dataene må sendes inn igjen.
Kodingstype (enctype attributt)	application / x-www-skjema-urlencoded	multipart / form-data eller applikasjon / x-www-form-urlencoded Bruk multipartkoding for binære data.
parametere	kan sende, men parameterdataene er begrenset til det vi kan legge inn på forespørselslinjen (URL). Sikkert å bruke mindre enn 2K parametere, håndterer noen servere opp til 64K	Kan sende parametere, inkludert opplasting av filer, til serveren.
hacket	Lettere å hacke for skriptkiddier	Vanskeligere å hacke
Begrensninger på skjema datatype	Ja, bare ASCII-tegn tillatt.	Ingen restriksjoner. Binær data er også tillatt.
Sikkerhet	GET er mindre sikker i forhold til POST fordi data som sendes er en del av nettadressen. Så det er lagret i nettleserhistorikk og serverlogger i ren tekst.	POST er litt sikrere enn GET fordi parametrene ikke lagres i nettleserloggen eller i webserverloggene.
Begrensninger på skjemadatellengde	Ja, siden skjemadata er i nettadressen og URL-lengden er begrenset. En sikker URL-lengdegrense er ofte 2048 tegn, men varierer fra nettleser og webserver.	Ingen restriksjoner
Usability	GET-metoden bør ikke brukes når du sender passord eller annen sensitiv informasjon.	POST-metode som brukes når du sender passord eller annen sensitiv informasjon.
Synlighet	GET-metoden er synlig for alle (den vises i nettleserens adresselinje) og har begrensninger på mengden informasjon som skal sendes.	POST-metodevariabler vises ikke i nettadressen.
bufret	Kan bufres	Ikke bufret

Innhold: GET vs POST

1 Forskjeller i skjemainnlevering
- 1.1 Fordeler og ulemper
2 forskjeller i server-side behandling
3 Anbefalt bruk
4 Hva med HTTPS?
5 referanser

Forskjeller i skjemainnlevering

Den grunnleggende forskjellen mellom METODE = "GET" og METODE = "POST" er det de svarer til forskjellige HTTP-forespørsler, som definert i HTTP-spesifikasjonene. Innleveringsprosessen for begge metodene begynner på samme måte - et skjema datasett er konstruert av nettleseren og deretter kodet på en måte som er spesifisert av enctype Egenskap. Til METODE = "POST de enctype attributt kan være multipart / skjema-data eller application / x-www-skjema-urlencoded, mens for METODE = "GET", bare application / x-www-skjema-urlencoded er tillatt. Dette skjema datasettet overføres deretter til serveren.

For skjema innsending med METHOD = "GET", konstruerer nettleseren en URL ved å ta verdien av handling attributt, legg til a ? til det, og legger til skjema datasettet (kodet ved hjelp av søknaden / x-www-form-urlenkodet innholdstype). Nettleseren behandler deretter denne nettadressen som om den følger en lenke (eller som om brukeren hadde skrevet nettadressen direkte). Nettleseren deler nettadressen i deler og gjenkjenner en vert, og sender deretter en GET-forespørsel til den verten med resten av nettadressen som argument. Serveren tar den derfra. Merk at denne prosessen betyr at skjemadataene er begrenset til ASCII-koder. Spesiell forsiktighet bør tas for å kode og avkode andre typer tegn når de overføres via URL-adressen i ASCII-format.

Innlevering av et skjema med METODE = "POST" fører til at en POST-forespørsel sendes, ved hjelp av verdien av handling attributt og en melding opprettet i henhold til innholdstypen spesifisert av enctype Egenskap.

Fordeler og ulemper

Siden skjemadata sendes som en del av nettadressen når FÅ benyttes --

Formdata er begrenset til ASCII-koder. Spesiell forsiktighet bør tas for å kode og avkode andre typer tegn når de overføres via URL-adressen i ASCII-format. På den annen side kan binære data, bilder og andre filer alle sendes inn gjennom METODE = "POST"
Alle skjemadata som er fylt inn, er synlige i nettadressen. Dessuten lagres den også i brukerens nettleserhistorikk / logger for nettleseren. Disse problemene gjør FÅ mindre sikker.
En fordel med skjemadata som sendes som en del av nettadressen er imidlertid at man kan bokmerke nettadressene og bruke dem direkte og helt omgå formularfyllingsprosessen.
Det er en begrensning på hvor mye skjema data kan sendes fordi URL lengder er begrenset.
Script kiddies kan lettere utsette sårbarheter i systemet for å hacke det. For eksempel ble Citibank hacket ved å endre kontonumre i URL-strengen.^[1] Selvfølgelig kan erfarne hackere eller webutviklere utsette slike sårbarheter, selv om POST brukes. det er bare litt vanskeligere. Generelt må serveren være mistenkelig for data som er sendt av klienten og vakt mot usikre, direkte objekttilfeller.

Forskjeller i server-sidebehandling

I prinsippet er behandling av innleverte formdata avhengig av om den sendes med METODE = "GET" eller METODE = "POST". Siden dataene er kodet på forskjellige måter, er det nødvendig med forskjellige dekoderingsmekanismer. Således kan endring av METODEN generelt nødvendiggjøre en endring i skriptet som behandler innlevering. For eksempel, når du bruker CGI-grensesnittet, mottar skriptet dataene i en miljøvariabel (QUERYSTRING) når FÅ benyttes. Men når POST brukes, blir skjemadata passert i standardinndatastrømmen (stdin) og antall byte som skal leses, er gitt av Innholdslengdeheader.

Anbefalt bruk

GET anbefales når du sender inn "idempotent" skjemaer - de som ikke "signifikant endrer verdens tilstand". Med andre ord, formularer som bare involverer databasesøk. Et annet perspektiv er at flere idempotente søk vil ha samme effekt som en enkelt spørring. Hvis databaseoppdateringer eller andre handlinger som utløser e-post er involvert, anbefales bruk av POST.

Fra Dropbox-utviklerbloggen:

en nettleser vet ikke nøyaktig hva en bestemt HTML-skjema gjør, men hvis skjemaet sendes via HTTP GET, vet nettleseren at det er trygt å prøve på nytt automatisk hvis det er en nettverksfeil. For skjemaer som bruker HTTP POST, kan det hende at det ikke er trygt å prøve på nytt, slik at nettleseren ber brukeren om bekreftelse først.

En "GET" forespørsel er ofte cacheable, mens en "POST" forespørsel knapt kan være. For spørringssystemer kan dette ha en betydelig effektivitetspåvirkning, spesielt hvis spørringsstrengene er enkle, siden kufferter kan tjene de hyppigste spørsmålene.

I enkelte tilfeller bruker POST anbefales selv for idempotente spørsmål:

Hvis skjemadataene vil inneholde ikke-ASCII-tegn (for eksempel aksenttegn), da METODE = "GET" kan ikke brukes i prinsippet, selv om det kan fungere i praksis (hovedsakelig for ISO Latin 1 tegn).
Hvis skjema datasettet er stort - si, hundrevis av tegn - da METODE = "GET" kan forårsake praktiske problemer med implementeringer som ikke kan håndtere de lange nettadressene.
Du ønsker kanskje å unngå METODE = "GET" for å gjøre det mindre synlig for brukerne hvordan skjemaet fungerer, spesielt for å gjøre "skjulte" felt (INPUT TYPE = "HIDDEN") mer skjult ved ikke å vises i nettadressen. Men selv om du bruker skjulte felt med METODE = "POST", de vil fremdeles vises i HTML-kilden.

Hva med HTTPS?

Oppdatert 15. mai 2015: Spesielt når du bruker HTTPS (HTTP over TLS / SSL), tilbyr POST noe mer sikkerhet enn GET?

Dette er et interessant spørsmål. Si at du gjør en GET-forespørsel til en nettside:

 FÅ https://www.example.com/login.php?user=mickey&passwd=mini

Forutsatt at din Internett-tilkobling blir overvåket, vil hvilken informasjon om denne forespørselen være tilgjengelig for snooper? Hvis POST brukes i stedet, og bruker- og passwd-data er inkludert i POST-variabler, vil det være sikrere når det gjelder HTTPS-tilkoblinger?

Svaret er nei. Hvis du gjør en slik GET-forespørsel, vil bare følgende informasjon bli kjent for angriperen som overvåker webtrafikken din:

Det faktum at du lagde en HTTPS-tilkobling
Vertsnavnet - www.eksempel.no
Den totale lengden på forespørselen
Lengden på svaret

Banens del av nettadressen - det vil si den aktuelle siden som er forespurt, samt spørringsstrengparametrene - er beskyttet (kryptert) mens de er "over ledningen", dvs. i transitt på vei til målserveren. Situasjonen er nøyaktig den samme for POST-forespørsler.

Selvfølgelig har webservere en tendens til å logge hele nettadressen i ren tekst i deres tilgangslogger; så å sende sensitiv informasjon over GET er ikke en god ide. Dette gjelder uavhengig av om HTTP eller HTTPS brukes.

referanser

wikipedia: POST (HTTP)
HTTP-forespørselsmetoder
HTTP-innlegg - W3.org
HTTP Get - W3.org
Skjuler HTTPS nettadressene som er tilgjengelige? - Stack Exchange

Teknologi