KRIJGEN versus POST

HTTP POST verzoeken leveren extra gegevens van de client (browser) aan de server in de berichttekst. In tegenstelling tot, KRIJGEN verzoeken bevatten alle vereiste gegevens in de URL. Formulieren in HTML kunnen beide methoden gebruiken door op te geven method = "POST" of method = "GET" (standaard) in de element. De opgegeven methode bepaalt hoe formuliergegevens naar de server worden verzonden. Wanneer de methode GET is, worden alle formuliergegevens gecodeerd in de URL, toegevoegd aan de actie URL als queryreeksparameters. Met POST worden formuliergegevens weergegeven in de berichttekst van het HTTP-verzoek.

Vergelijkingstabel

GET versus POST-vergelijkingsgrafiek

KRIJGEN	POST

Geschiedenis	Parameters blijven in de browsergeschiedenis omdat ze deel uitmaken van de URL	Parameters worden niet opgeslagen in de browsergeschiedenis.
bookmarked	Kan als bladwijzer worden gebruikt.	Kan niet als bladwijzer worden gebruikt.
BACK-knop / opnieuw aanmelden	GET-verzoeken worden opnieuw uitgevoerd, maar mogen niet opnieuw naar de server worden verzonden als de HTML in de browsercache is opgeslagen.	De browser waarschuwt de gebruiker meestal dat gegevens opnieuw moeten worden ingediend.
Coderingstype (kenmerk enctype)	application / x-www-form-urlencoded	multipart / form-data of application / x-www-form-urlencoded Gebruik multipart-codering voor binaire gegevens.
parameters	kan verzenden, maar de parametergegevens zijn beperkt tot wat we in de aanvraagregel (URL) kunnen stoppen. Het veiligst om minder dan 2 K parameters te gebruiken, sommige servers kunnen tot 64K aan	Kan parameters, inclusief het uploaden van bestanden, naar de server verzenden.
hacked	Makkelijker te hacken voor scriptkiddies	Moeilijker om te hacken
Beperkingen op formuliergegevenstype	Ja, alleen ASCII-tekens toegestaan.	Geen beperkingen. Binaire gegevens zijn ook toegestaan.
Veiligheid	GET is minder veilig in vergelijking met POST omdat de verzonden gegevens deel uitmaken van de URL. Dus het wordt opgeslagen in browsergeschiedenis en serverlogboeken in leesbare tekst.	POST is een beetje veiliger dan GET omdat de parameters niet worden opgeslagen in de browsergeschiedenis of in webserverlogboeken.
Beperkingen op de lengte van de formuliergegevens	Ja, omdat formuliergegevens in de URL staan en de URL-lengte beperkt is. Een veilige URL-lengtelimiet is vaak 2048 tekens, maar varieert per browser en webserver.	Geen beperkingen
Usability	GET-methode mag niet worden gebruikt bij het verzenden van wachtwoorden of andere gevoelige informatie.	POST-methode die wordt gebruikt bij het verzenden van wachtwoorden of andere gevoelige informatie.
Zichtbaarheid	De methode GET is zichtbaar voor iedereen (deze wordt weergegeven in de adresbalk van de browser) en heeft limieten voor de hoeveelheid informatie die moet worden verzonden.	POST-methode variabelen worden niet weergegeven in de URL.
In cache	Kan in de cache worden bewaard	Niet in de cache

Inhoud: GET versus POST

1 Verschillen in formulierverzending
- 1.1 Voors en tegens
2 Verschillen in server-side verwerking
3 Aanbevolen gebruik
4 Hoe zit het met HTTPS?
5 Referenties

Verschillen in formulierverzending

Het fundamentele verschil tussen METHOD = "GET" en METHOD = "POST" is dat ze corresponderen met verschillende HTTP-verzoeken, zoals gedefinieerd in de HTTP-specificaties. Het indieningsproces voor beide methoden begint op dezelfde manier - een formuliergegevensset wordt door de browser geconstrueerd en vervolgens op een door de browser gespecificeerde manier gecodeerd enctype attribuut. Voor METHOD = "POST de enctype attribuut kan zijn multipart / form-data of application / x-www-form-urlencoded, terwijl voor METHOD = "GET", enkel en alleen application / x-www-form-urlencoded is toegestaan. Deze formuliergegevensset wordt vervolgens naar de server verzonden.

Voor formulierinzending met METHOD = "GET", construeert de browser een URL door de waarde van de actie attribuut, toevoegend a ? erop en vervolgens de formuliergegevensset toe te voegen (gecodeerd met het inhoudstype application / x-www-form-urlencoded). De browser verwerkt deze URL vervolgens alsof hij een link volgt (of alsof de gebruiker de URL rechtstreeks had getypt). De browser verdeelt de URL in delen en herkent een host en verzendt vervolgens naar die host een GET-verzoek met de rest van de URL als argument. De server neemt het vanaf daar. Merk op dat dit proces betekent dat de formuliergegevens beperkt zijn tot ASCII-codes. Speciale aandacht moet worden besteed aan het coderen en decoderen van andere soorten tekens bij het doorgeven van de URL in ASCII-indeling.

Indienen van een formulier met METHOD = "POST" veroorzaakt dat een POST-verzoek wordt verzonden, gebruikmakend van de waarde van de actie attribuut en een bericht gemaakt volgens het inhoudstype gespecificeerd door de enctype attribuut.

Voors en tegens

Aangezien formuliergegevens worden verzonden als onderdeel van de URL wanneer KRIJGEN is gebruikt --

Formuliergegevens zijn beperkt tot ASCII-codes. Speciale aandacht moet worden besteed aan het coderen en decoderen van andere soorten tekens bij het doorgeven van de URL in ASCII-indeling. Aan de andere kant kunnen binaire gegevens, afbeeldingen en andere bestanden allemaal worden ingediend METHOD = "POST"
Alle ingevulde formuliergegevens zijn zichtbaar in de URL. Bovendien wordt het ook opgeslagen in de webbrowsergeschiedenis / -logboeken van de gebruiker voor de browser. Deze problemen maken KRIJGEN minder veilig.
Eén voordeel van formuliergegevens die als deel van de URL worden verzonden, is echter dat u de URL's kunt bookmarken en deze direct kunt gebruiken en het formuliervulproces volledig kunt omzeilen.
Er is een beperking op de hoeveelheid formuliergegevens die kunnen worden verzonden omdat de URL-lengte beperkt is.
Scriptkiddies kunnen kwetsbaarheden in het systeem gemakkelijker blootleggen om het te hacken. Citibank is bijvoorbeeld gehackt door accountnummers in de URL-reeks te wijzigen.^[1] Natuurlijk kunnen ervaren hackers of webontwikkelaars dergelijke kwetsbaarheden blootleggen, zelfs als POST wordt gebruikt; het is gewoon een beetje moeilijker. Over het algemeen moet de server achterdochtig zijn voor alle gegevens die door de client worden verzonden en zich wapenen tegen verwijzingen naar Insecure Direct Object.

Verschillen in Server-Side Processing

In principe is de verwerking van ingediende formuliergegevens afhankelijk van of deze wordt verzonden met METHOD = "GET" of METHOD = "POST". Omdat de gegevens op verschillende manieren zijn gecodeerd, zijn verschillende decoderingsmechanismen nodig. Dus in het algemeen kan het veranderen van de METHODE een wijziging van het script vereisen dat de inzending verwerkt. Als u bijvoorbeeld de CGI-interface gebruikt, ontvangt het script de gegevens in een omgevingsvariabele (QUERYSTRING) wanneer KRIJGEN is gebruikt. Maar wanneer POST wordt gebruikt, worden formuliergegevens doorgegeven in de standaard invoerstroom (stdin) en het aantal te lezen bytes wordt gegeven door de kop Content-length.

Aanbevolen gebruik

GET wordt aanbevolen bij het indienen van "idempotente" formulieren - die vormen die 'de toestand van de wereld' niet significant veranderen '. Met andere woorden, formulieren die alleen betrekking hebben op databasequery's. Een ander perspectief is dat verschillende idempotente queries hetzelfde effect hebben als een enkele query. Als er database-updates of andere acties zoals het activeren van e-mails zijn, wordt het gebruik van POST aanbevolen.

Van de Dropbox-blog voor ontwikkelaars:

een browser weet niet precies wat een bepaald HTML-formulier doet, maar als het formulier wordt ingediend via HTTP GET, weet de browser dat het veilig is om automatisch opnieuw te verzenden als er een netwerkfout is. Voor formulieren die HTTP POST gebruiken, kan het niet veilig zijn om opnieuw te proberen, dus vraagt de browser de gebruiker eerst om een bevestiging.

Een "GET" -aanvraag is vaak cacheerbaar, terwijl een "POST" -verzoek nauwelijks kan zijn. Voor query-systemen kan dit een aanzienlijke efficiëntie-impact hebben, vooral als de queryreeksen eenvoudig zijn, omdat caches de meest voorkomende zoekopdrachten kunnen zijn.

In bepaalde gevallen, gebruiken POST wordt zelfs aanbevolen voor idempotent query's:

Als de formuliergegevens niet-ASCII-tekens zouden bevatten (zoals tekens met accenten), dan METHOD = "GET" is in principe niet van toepassing, hoewel het in de praktijk wel kan werken (voornamelijk voor ISO Latin 1-tekens).
Als de formuliergegevensset groot is - zeg honderden karakters - dan METHOD = "GET" kan praktische problemen veroorzaken met implementaties die deze lange URL's niet aankunnen.
Misschien wilt u dit vermijden METHOD = "GET" om het minder zichtbaar te maken voor gebruikers hoe het formulier werkt, vooral om "verborgen" velden (INPUT TYPE = "HIDDEN") meer verborgen te maken door niet in de URL te verschijnen. Maar zelfs als u verborgen velden gebruikt met METHOD = "POST", ze verschijnen nog steeds in de HTML-broncode.

Hoe zit het met HTTPS?

Bijgewerkt 15 mei 2015: biedt POST met name meer beveiliging dan GET als u HTTPS (HTTP over TLS / SSL) gebruikt?

Dit is een interessante vraag. Stel dat u een GET-aanvraag doet naar een webpagina:

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

Ervan uitgaande dat uw internetverbinding wordt gecontroleerd, welke informatie over dit verzoek zal beschikbaar zijn voor de snooper? Als POST in plaats daarvan wordt gebruikt en de gegevens van de gebruiker en passwd worden opgenomen in POST-variabelen, is dat veiliger in het geval van HTTPS-verbindingen?

Het antwoord is nee. Als u een dergelijk GET-verzoek indient, weet de aanvaller alleen de volgende informatie over uw internetverkeer:

Het feit dat je een HTTPS-verbinding hebt gemaakt
De hostnaam - www.example.com
De totale lengte van het verzoek
De lengte van het antwoord

Het padgedeelte van de URL - d.w.z. de feitelijk gevraagde pagina, evenals de parameters van de vraagstring - worden beschermd (versleuteld) terwijl zij "over de draad" zijn, d.w.z. tijdens het transport op weg naar de bestemmingsserver. De situatie is precies hetzelfde voor POST-aanvragen.

Natuurlijk hebben webservers de neiging om de volledige URL in platte tekst in hun toegangslogboeken te loggen; dus het verzenden van gevoelige informatie over GET is geen goed idee. Dit is van toepassing ongeacht of HTTP of HTTPS wordt gebruikt.

Referenties

wikipedia: POST (HTTP)
HTTP-verzoekmethoden
HTTP-bericht - W3.org
HTTP Get - W3.org
Verbergt HTTPS de URL's die worden geopend? - Stack Exchange

Technologie