GET vs. POST

HTTP POST Anfragen liefern zusätzliche Daten vom Client (Browser) an den Server im Nachrichtentext. Im Gegensatz, ERHALTEN Anfragen enthalten alle erforderlichen Daten in der URL. Formulare in HTML können beide Methoden verwenden, indem sie angeben method = "POST" oder method = "GET" (Standardeinstellung) in der Element. Die angegebene Methode bestimmt, wie Formulardaten an den Server übermittelt werden. Wenn die Methode GET ist, werden alle Formulardaten in die URL codiert und an die angefügt Aktion URL als Abfragezeichenfolgeparameter. Mit POST werden Formulardaten im Nachrichtentext der HTTP-Anforderung angezeigt.

Vergleichstabelle

GET versus POST-Vergleichstabelle

ERHALTEN	POST

Geschichte	Parameter bleiben im Browserverlauf, da sie Teil der URL sind	Parameter werden nicht im Browserverlauf gespeichert.
Vorgemerkt	Kann mit einem Lesezeichen versehen werden.	Kann nicht mit einem Lesezeichen versehen werden.
BACK-Taste / Verhalten erneut einreichen	GET-Anforderungen werden erneut ausgeführt, können jedoch nicht erneut an den Server übermittelt werden, wenn der HTML-Code im Browser-Cache gespeichert ist.	Der Browser weist den Benutzer normalerweise darauf hin, dass die Daten erneut übermittelt werden müssen.
Kodierungstyp (Attribut "enctype")	application / x-www-form-urlencoded	multipart / form-data oder application / x-www-form-urlencoded Verwenden Sie die mehrteilige Codierung für binäre Daten.
Parameter	kann senden, aber die Parameterdaten sind auf das beschränkt, was wir in die Anforderungszeile (URL) einfügen können. Am sichersten, um weniger als 2 KByte Parameter zu verwenden, können einige Server bis zu 64 KByte verarbeiten	Kann Parameter, einschließlich Hochladen von Dateien, an den Server senden.
Gehackt	Einfacher für Script-Kids zu hacken	Schwieriger zu hacken
Einschränkungen beim Formulardatentyp	Ja, nur ASCII-Zeichen sind zulässig.	Keine Einschränkungen. Binäre Daten sind ebenfalls zulässig.
Sicherheit	GET ist im Vergleich zum POST weniger sicher, da die gesendeten Daten Teil der URL sind. Es wird also im Browserverlauf und Serverprotokolle im Klartext gespeichert.	POST ist etwas sicherer als GET, da die Parameter nicht im Browserverlauf oder in Webserverprotokollen gespeichert werden.
Einschränkungen der Formulardatenlänge	Ja, da Formulardaten in der URL enthalten sind und die URL-Länge begrenzt ist. Die Länge einer sicheren URL-Länge beträgt oft 2048 Zeichen, variiert jedoch je nach Browser und Webserver.	Keine Einschränkungen
Verwendbarkeit	Die GET-Methode sollte nicht verwendet werden, wenn Passwörter oder andere vertrauliche Informationen gesendet werden.	POST-Methode, die beim Senden von Passwörtern oder anderen vertraulichen Informationen verwendet wird.
Sichtweite	Die GET-Methode ist für alle sichtbar (wird in der Adressleiste des Browsers angezeigt) und die Anzahl der zu sendenden Informationen ist begrenzt.	POST-Methodenvariablen werden in der URL nicht angezeigt.
Zwischengespeichert	Kann zwischengespeichert werden	Nicht zwischengespeichert

Inhalt: GET vs POST

1 Unterschiede bei der Formularübermittlung
- 1.1 Vor- und Nachteile
2 Unterschiede bei der serverseitigen Verarbeitung
3 Empfohlene Verwendung
4 Was ist mit HTTPS??
5 Referenzen

Unterschiede bei der Formulareinreichung

Der grundlegende Unterschied zwischen METHOD = "GET" und METHOD = "POST" ist, dass sie entsprechen verschiedene HTTP-Anforderungen, wie in den HTTP-Spezifikationen definiert. Der Übermittlungsprozess für beide Methoden beginnt auf die gleiche Weise: Ein Formulardatensatz wird vom Browser erstellt und dann in einer durch das Format festgelegten Weise codiert enctype Attribut. Zum METHOD = "POST das enctype Attribut kann sein Multipart / Formulardaten oder application / x-www-form-urlencoded, während für METHOD = "GET", nur application / x-www-form-urlencoded ist erlaubt. Dieser Formulardatensatz wird dann an den Server übermittelt.

Für die Formularübermittlung mit METHOD = "GET" erstellt der Browser eine URL, indem er den Wert von übernimmt Aktion Attribut, anhängen a ? Anhängen des Formulardatensatzes (codiert mit dem Inhaltstyp application / x-www-form-urlencoded). Der Browser verarbeitet diese URL dann so, als würde er einem Link folgen (oder als hätte der Benutzer die URL direkt eingegeben). Der Browser teilt die URL in Teile auf, erkennt einen Host und sendet dann eine GET-Anforderung mit dem Rest der URL an diesen Host als Argument. Der Server nimmt es von dort aus. Beachten Sie, dass dieser Prozess bedeutet, dass die Formulardaten auf ASCII-Codes beschränkt sind. Bei der Weiterleitung durch die URL im ASCII-Format ist besonders darauf zu achten, dass andere Zeichenarten codiert und decodiert werden.

Das Senden eines Formulars mit METHOD = "POST" bewirkt, dass eine POST-Anforderung mit dem Wert von gesendet wird Aktion Attribut und eine Nachricht, die entsprechend dem durch den angegebenen Inhaltstyp erstellt wurde enctype Attribut.

Vor-und Nachteile

Da werden Formulardaten als Teil der URL gesendet ERHALTEN wird eingesetzt --

Formulardaten sind auf ASCII-Codes beschränkt. Bei der Weiterleitung durch die URL im ASCII-Format ist besonders darauf zu achten, dass andere Zeichenarten codiert und decodiert werden. Auf der anderen Seite können binäre Daten, Bilder und andere Dateien übermittelt werden METHOD = "POST"
Alle ausgefüllten Formulardaten sind in der URL sichtbar. Darüber hinaus wird es auch in den Browserverlauf / -protokollen des Benutzers für den Browser gespeichert. Diese Fragen machen ERHALTEN weniger sicher.
Ein Vorteil des Versendens von Formulardaten als Teil der URL besteht jedoch darin, dass die URLs mit einem Lesezeichen versehen und direkt verwendet werden können und den Formularfüllvorgang vollständig umgehen können.
Es gibt eine Einschränkung, wie viel Formulardaten gesendet werden können, da die URL-Längen begrenzt sind.
Skriptkiddies können Schwachstellen im System leichter aufdecken, um sie zu hacken. Beispielsweise wurde die Citibank durch Ändern der Kontonummern in der URL-Zeichenfolge gehackt.^[1] Erfahrene Hacker oder Webentwickler können solche Sicherheitsanfälligkeiten natürlich auch dann offen legen, wenn POST verwendet wird. es ist nur ein bisschen schwieriger. Im Allgemeinen muss der Server den vom Client gesendeten Daten verdächtigen und vor unsicheren direkten Objektverweisen schützen.

Unterschiede in der serverseitigen Verarbeitung

Grundsätzlich hängt die Verarbeitung eines übermittelten Formulars davon ab, ob mitgesendet wird METHOD = "GET" oder METHOD = "POST". Da die Daten auf unterschiedliche Weise codiert werden, sind unterschiedliche Dekodierungsmechanismen erforderlich. Daher kann das Ändern der METHODE im Allgemeinen eine Änderung des Skripts erforderlich machen, das die Einreichung verarbeitet. Bei Verwendung der CGI-Schnittstelle erhält das Skript beispielsweise die Daten in einer Umgebungsvariablen (QUERYSTRING), wenn ERHALTEN wird eingesetzt. Aber wenn POST verwendet wird, werden Formulardaten im Standardeingabestrom übergeben (stdin) und die Anzahl der zu lesenden Bytes wird durch den Content-Length-Header angegeben.

Empfohlene Verwendung

GET wird empfohlen, wenn "idempotente" Formulare eingereicht werden - solche, die den Zustand der Welt nicht wesentlich verändern. Mit anderen Worten, Formulare, die nur Datenbankabfragen enthalten. Eine andere Perspektive ist, dass mehrere idempotente Abfragen dieselbe Wirkung haben wie eine einzelne Abfrage. Wenn Datenbankaktualisierungen oder andere Aktionen wie das Auslösen von E-Mails beteiligt sind, wird die Verwendung von POST empfohlen.

Aus dem Dropbox-Entwicklerblog:

Ein Browser weiß nicht genau, was ein bestimmtes HTML-Formular tut, aber wenn das Formular über HTTP GET gesendet wird, weiß der Browser, dass es sicher ist, die Übermittlung bei einem Netzwerkfehler automatisch erneut zu versuchen. Bei Formularen, die HTTP POST verwenden, kann es möglicherweise nicht sicher sein, es erneut zu versuchen, sodass der Browser den Benutzer zunächst zur Bestätigung auffordert.

Eine "GET" -Anforderung kann häufig zwischengespeichert werden, wohingegen eine "POST" -Anforderung kaum möglich sein kann. Bei Abfragesystemen kann dies erhebliche Auswirkungen auf die Effizienz haben, insbesondere wenn die Abfragezeichenfolgen einfach sind, da Caches möglicherweise die häufigsten Abfragen bedienen.

In bestimmten Fällen verwenden Sie POST wird auch für idempotente Abfragen empfohlen:

Wenn die Formulardaten Nicht-ASCII-Zeichen enthalten würden (wie Zeichen mit Akzent), dann METHOD = "GET" ist prinzipiell nicht anwendbar, obwohl es in der Praxis funktionieren kann (hauptsächlich für ISO-1-Zeichen).
Wenn der Formulardatensatz groß ist - sagen wir Hunderte von Zeichen - dann METHOD = "GET" kann praktische Probleme bei Implementierungen verursachen, die diese langen URLs nicht verarbeiten können.
Sie möchten vielleicht vermeiden METHOD = "GET" Um den Benutzern die Funktionsweise des Formulars weniger sichtbar zu machen, insbesondere um "ausgeblendete" Felder (INPUT TYPE = "HIDDEN") auszublenden, indem sie nicht in der URL angezeigt werden. Aber auch wenn Sie versteckte Felder mit verwenden METHOD = "POST", Sie werden weiterhin im HTML-Quellcode angezeigt.

Was ist mit HTTPS??

Aktualisiert am 15. Mai 2015: Insbesondere bei Verwendung von HTTPS (HTTP über TLS / SSL) bietet der POST mehr Sicherheit als GET?

Dies ist eine interessante Frage. Angenommen, Sie stellen eine GET-Anfrage an eine Webseite:

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

Angenommen, Ihre Internetverbindung wird überwacht. Welche Informationen zu dieser Anforderung stehen dem Snooper zur Verfügung? Wenn stattdessen POST verwendet wird und die Benutzer- und passwd-Daten in POST-Variablen enthalten sind, ist dies bei HTTPS-Verbindungen sicherer?

Die Antwort ist nein. Wenn Sie eine solche GET-Anfrage stellen, werden dem Angreifer, der Ihren Webdatenverkehr überwacht, nur die folgenden Informationen angezeigt:

Die Tatsache, dass Sie eine HTTPS-Verbindung hergestellt haben
Der Hostname - www.example.com
Die Gesamtlänge der Anfrage
Die Länge der Antwort

Der Pfadteil der URL - d. H. Die tatsächlich angeforderte Seite, sowie die Abfragezeichenfolgeparameter - werden geschützt (verschlüsselt), während sie "über die Leitung" sind, d. H. Auf dem Weg zum Zielserver. Die Situation ist für POST-Anfragen genau dieselbe.

Natürlich neigen Webserver dazu, die gesamte URL in Klartext in ihren Zugriffsprotokollen zu protokollieren. Das Senden sensibler Informationen über GET ist daher keine gute Idee. Dies gilt unabhängig davon, ob HTTP oder HTTPS verwendet wird.

Verweise

wikipedia: POST (HTTP)
HTTP-Anforderungsmethoden
HTTP Post - W3.org
HTTP Get - W3.org
Verbirgt HTTPS die URLs, auf die zugegriffen wird? - Stapelaustausch

Technologie