GET vs. POST

HTTP POSTA begäran lämnar ytterligare data från klienten (webbläsaren) till servern i meddelandekroppen. I kontrast, SKAFFA SIG Förfrågningar inkluderar alla nödvändiga uppgifter i webbadressen. Blanketter i HTML kan använda endera metoden genom att ange method = "POST" eller metod = "GET" (standard) i element. Den angivna metoden avgör hur formulärdata skickas till servern. När metoden är GET kodas alla formulärdata till webbadressen, bifogad till verkan URL som söksträngsparametrar. Med POST visas formulärdata i meddelandekroppen för HTTP-förfrågan.

Jämförelsediagram

GET mot POST jämförelse diagram

SKAFFA SIG	POSTA

Historia	Parametrarna kvarstår i webbläsarhistoriken eftersom de ingår i webbadressen	Parametrar sparas inte i webbläsarhistoriken.
bokmärkt	Kan bokmärkas.	Kan inte bokmärkas.
BACK-knapp / inlämning av beteende	GET-förfrågningar utförs igen men får inte skickas till servern om HTML lagras i webbläsarens cache.	Webbläsaren varnar vanligtvis användaren om att uppgifterna måste skickas in igen.
Kodningstyp (Enctype-attribut)	application / x-www-form-urlencoded	multipart / form-data eller application / x-www-form-urlencoded Använd multipartkodning för binär data.
parametrar	kan skicka men parameterdata begränsas till vad vi kan spåra i begäran linje (URL). Säkerast att använda mindre än 2K parametrar, hanterar vissa servrar upp till 64K	Kan skicka parametrar, inklusive uppladdning av filer, till servern.
hackad	Lättare att hacka för skriptkiddier	Svårare att hacka
Begränsningar av formulärdatatyp	Ja, endast ASCII-tecken är tillåtna.	Inga begränsningar. Binär data är också tillåtet.
säkerhet	GET är mindre säker jämfört med POST eftersom data som skickas är en del av webbadressen. Så det sparas i webbläsarhistorik och serverns loggar i ren text.	POST är lite säkrare än GET eftersom parametrarna inte lagras i webbläsarhistoriken eller i webbserverloggar.
Begränsningar av formulärets längd	Ja, eftersom formulärdata finns i webbadressen och URL-längden är begränsad. En säker URL-längdgräns är ofta 2048 tecken men varierar via webbläsare och webbserver.	Inga begränsningar
användbarhet	GET-metoden ska inte användas när du skickar lösenord eller annan känslig information.	POST-metod som används när du skickar lösenord eller annan känslig information.
Synlighet	GET-metoden är synlig för alla (den kommer att visas i webbläsarens adressfält) och har gränser för hur mycket information som ska skickas.	POST-metodvariabler visas inte i webbadressen.
cachad	Kan cachas	Ej cachad

Innehåll: GET vs POST

1 Skillnader i formulärinsändning
- 1.1 Fördelar och nackdelar
2 Skillnader i server-sidbehandling
3 Rekommenderad användning
4 Vad sägs om HTTPS?
5 referenser

Skillnader i formulärinsändning

Den grundläggande skillnaden mellan Method = "GET" och Method = "POST" är att de motsvarar olika HTTP-förfrågningar, enligt definitionen i HTTP-specifikationerna. Inlämningsprocessen för båda metoderna börjar på samma sätt - en formulärdatasats konstrueras av webbläsaren och kodas sedan på ett sätt som anges av enctype attribut. För Method = "POST de enctype attributet kan vara multipart / form-data eller application / x-www-form-urlencoded, medan för Method = "GET", endast application / x-www-form-urlencoded är tillåtet. Den här formulärdatasatsen överförs sedan till servern.

För formulärinsändning med METHOD = "GET", konstruerar webbläsaren en URL genom att ta värdet av verkan attribut, lägg till en ? till det, och lägger sedan till formulärdatasatsen (kodad med hjälp av program / x-www-form-urlenkodad innehållstyp). Webbläsaren behandlar sedan den här webbadressen som om den följer en länk (eller som om användaren hade skrivit webbadressen direkt). Webbläsaren delar upp webbadressen i delar och känner igen en värd och skickar sedan till den värden en GET-förfrågan med resten av webbadressen som argument. Servern tar det därifrån. Observera att denna process innebär att formulärdata är begränsade till ASCII-koder. Särskild försiktighet bör vidtas för att koda och avkoda andra typer av tecken när de skickas via URL-adressen i ASCII-format.

Inlämning av en blankett med METHOD = "POST" orsakar en POST-förfrågan som ska skickas, med värdet av verkan attribut och ett meddelande skapat enligt innehållstypen som anges av enctype attribut.

För-och nackdelar

Eftersom formulärdata skickas som en del av webbadressen när SKAFFA SIG är använd --

Formdata är begränsade till ASCII-koder. Särskild försiktighet bör vidtas för att koda och avkoda andra typer av tecken när de skickas via URL-adressen i ASCII-format. Å andra sidan kan binära data, bilder och andra filer skickas in via Method = "POST"
Alla formulärdata fyllda i är synliga i webbadressen. Dessutom lagras den också i användarens webbläsarhistorik / loggar för webbläsaren. Dessa problem gör SKAFFA SIG mindre säkra.
En fördel med formulärdata som skickas som en del av webbadressen är dock att man kan bokmärka webbadresserna och direkt använda dem och helt förbikoppla formulärfyllningsprocessen.
Det finns en begränsning av hur mycket formulärdata kan skickas eftersom URL-längder är begränsade.
Script kiddies kan lättare avslöja sårbarheter i systemet för att hacka det. Citibank har till exempel hackats genom att ändra kontonumren i URL-strängen.^[1] Självklart kan erfarna hackare eller webbutvecklare avslöja sådana sårbarheter även om POST används. det är bara lite svårare. I allmänhet måste servern vara misstänkt för alla data som skickas av klienten och skydda mot osäkra direkta objektreferenser.

Skillnader i server-sidbehandling

I princip beror behandlingen av inlämnade formuläruppgifter om den skickas med Method = "GET" eller Method = "POST". Eftersom data kodas på olika sätt behövs olika avkodningsmekanismer. Allmänt sett kan förändring av METODEN kräva en förändring av manuset som behandlar inlämningen. När du till exempel använder CGI-gränssnittet tar skriptet emot data i en miljövariabel (QUERYSTRING) när SKAFFA SIG är använd. Men när POSTA används, skickas formulärdata i standardinmatningsströmmen (stdin) och antalet byte som ska läsas ges av innehålls längdhuvudet.

Rekommenderad användning

GET rekommenderas vid inlämning av "idempotent" formulär - de som inte "väsentligt förändrar världens tillstånd". Med andra ord, former som endast involverar databasfrågor. Ett annat perspektiv är att flera idempotenta frågor kommer att ha samma effekt som en enda fråga. Om databasuppdateringar eller andra åtgärder som utlösande e-postmeddelanden är inblandade rekommenderas användningen av POST.

Från Dropbox-utvecklarbloggen:

en webbläsare vet inte exakt vad en viss HTML-blankett gör, men om formuläret skickas via HTTP GET, vet webbläsaren att det är säkert att försöka igen försändelsen automatiskt om det finns ett nätverksfel. För formulär som använder HTTP POST kan det vara säkert att försöka igen, så att webbläsaren frågar användaren för bekräftelse först.

En "GET" -förfrågan är ofta cacheable, medan en "POST" -förfrågan knappast kan vara. För frågeordningar kan detta ha en betydande effektivitetspåverkan, speciellt om frågesträngarna är enkla, eftersom kachor kan tjäna de vanligaste frågorna.

I vissa fall använder man POSTA rekommenderas även för idempotenta frågor:

Om formulärdata skulle innehålla icke-ASCII-tecken (som accenterade tecken), då Method = "GET" kan inte tillämpas i princip, även om det kan fungera i praktiken (huvudsakligen för ISO Latin 1 tecken).
Om formulärdatasatsen är stor - säg, hundratals tecken - då Method = "GET" kan orsaka praktiska problem med implementeringar som inte kan hantera de långa webbadresserna.
Du kanske vill undvika Method = "GET" för att göra det mindre synligt för användarna hur formuläret fungerar, speciellt för att göra "dolda" fält (INPUT TYPE = "HIDDEN") mer dolt genom att inte visas i webbadressen. Men även om du använder dolda fält med Method = "POST", de kommer fortfarande att visas i HTML-källkoden.

Vad sägs om HTTPS?

Uppdaterad 15 maj 2015: Speciellt när du använder HTTPS (HTTP över TLS / SSL), erbjuder POST mer säkerhet än GET?

Det här är en intressant fråga. Säg att du gör en GET-förfrågan på en webbsida:

 Hämta https://www.example.com/login.php?user=mickey&passwd=mini

Om du antar att din Internetanslutning övervakas, kommer vilken information om denna begäran att finnas tillgänglig för snooper? Om POST används istället, och användar- och passwd-data ingår i POST-variabler, kommer det att vara säkrare när det gäller HTTPS-anslutningar?

Svaret är nej. Om du gör en sådan GET-förfrågan kommer endast följande information att vara känd för den angripare som övervakar din webbtrafik:

Det faktum att du gjorde en HTTPS-anslutning
Värdnamnet - www.example.com
Den totala längden på begäran
Svarets längd

Banens webbadress - dvs den faktiska sidan som begärts, samt parametrarna för frågesträngen - är skyddade (krypterade) medan de är "över ledningen" dvs. i transit på väg till destinationsservern. Situationen är exakt densamma för POST-förfrågningar.

Naturligtvis tenderar webbservrar att logga hela webbadressen i vanlig text i deras åtkomstloggar; så att skicka känslig information över GET är inte en bra idé. Detta gäller oavsett om HTTP eller HTTPS används.

referenser

wikipedia: POST (HTTP)
HTTP-förfrågningsmetoder
HTTP-inlägg - W3.org
HTTP Get - W3.org
Hämtar HTTPS de webbadresser som nås? - Stack Exchange

Teknologi