GET vs. POST

HTTP- POST- Anforderungen liefern zusätzliche Daten vom Client (Browser) an den Server im Nachrichtentext. Im Gegensatz dazu enthalten GET- Anforderungen alle erforderlichen Daten in der URL. Formulare in HTML können entweder eine Methode verwenden, indem Sie method = "POST" oder method = "GET" (Standard) in angeben Element. Die angegebene Methode bestimmt, wie Formulardaten an den Server gesendet werden. Wenn die Methode GET ist, werden alle Formulardaten in die URL codiert und als Abfragezeichenfolgenparameter an die Aktions- URL angehängt. Bei POST werden Formulardaten im Nachrichtentext der HTTP-Anforderung angezeigt.

Vergleichstabelle

Vergleichstabelle GET versus POST
BEKOMMEN POST
GeschichteParameter bleiben im Browserverlauf, da sie Teil der URL sindParameter werden nicht im Browserverlauf gespeichert.
LesezeichenKann mit einem Lesezeichen versehen werden.Kann nicht mit einem Lesezeichen versehen werden.
Zurück-Schaltfläche / Verhalten erneut sendenGET-Anforderungen werden erneut ausgeführt, jedoch möglicherweise nicht erneut an den Server gesendet, wenn der HTML-Code im Browser-Cache gespeichert ist.Der Browser warnt den Benutzer normalerweise, dass Daten erneut übermittelt werden müssen.
Codierungstyp (Attribut enctype)application / x-www-form-urlencodedmultipart / form-data oder application / x-www-form-urlencoded Verwenden Sie die mehrteilige Codierung für Binärdaten.
Parameterkann senden, aber die Parameterdaten sind auf das beschränkt, was wir in die Anforderungszeile (URL) einfügen können. Einige Server verarbeiten am sichersten weniger als 2 KB Parameter und verarbeiten bis zu 64 KBKann Parameter, einschließlich des Hochladens von Dateien, an den Server senden.
GehacktEinfacher für Skriptkinder zu hackenSchwieriger zu hacken
Einschränkungen beim FormulardatentypJa, nur ASCII-Zeichen zulässig.Keine Einschränkungen. Binärdaten sind ebenfalls zulässig.
SicherheitGET ist im Vergleich zu POST weniger sicher, da die gesendeten Daten Teil der URL sind. Es wird also im Browserverlauf und in den Serverprotokollen im Klartext gespeichert.POST ist etwas sicherer als GET, da die Parameter nicht im Browserverlauf oder in Webserverprotokollen gespeichert sind.
Einschränkungen bei der Länge von FormulardatenJa, da sich Formulardaten in der URL befinden und die URL-Länge begrenzt ist. Eine sichere URL-Längenbeschränkung beträgt häufig 2048 Zeichen, variiert jedoch je nach Browser und Webserver.Keine Einschränkungen
BenutzerfreundlichkeitDie GET-Methode sollte nicht verwendet werden, wenn Kennwörter oder andere vertrauliche Informationen gesendet werden.POST-Methode zum Senden von Passwörtern oder anderen vertraulichen Informationen.
SichtweiteDie GET-Methode ist für alle sichtbar (sie wird in der Adressleiste des Browsers angezeigt) und die Anzahl der zu sendenden Informationen ist begrenzt.POST-Methodenvariablen werden in der URL nicht angezeigt.
ZwischengespeichertKann zwischengespeichert werdenNicht zwischengespeichert

Unterschiede in der Formularübermittlung

Der grundlegende Unterschied zwischen METHOD = "GET" und METHOD = "POST" besteht darin, dass sie unterschiedlichen HTTP-Anforderungen entsprechen, wie in den HTTP-Spezifikationen definiert. Der Übermittlungsprozess für beide Methoden beginnt auf dieselbe Weise: Ein Formulardatensatz wird vom Browser erstellt und dann in einer durch das Attribut enctype angegebenen Weise codiert. Für METHOD = "POST kann das Attribut enctype mehrteilig / Formulardaten oder application / x-www-form-urlencoded sein, während für METHOD =" GET " nur application / x-www-form-urlencoded zulässig ist. Diese Formulardaten set wird dann an den Server übertragen.

Für die Formularübermittlung mit METHOD = "GET" erstellt der Browser eine URL, indem er den Wert des Aktionsattributs verwendet und ein ? Fügen Sie dann den Formulardatensatz hinzu (codiert mit dem Inhaltstyp application / x-www-form-urlencoded). Der Browser verarbeitet diese URL dann so, als ob er einem Link folgt (oder als hätte der Benutzer die URL direkt eingegeben). Der Browser unterteilt die URL in Teile und erkennt einen Host. Anschließend sendet er eine GET-Anforderung mit dem Rest der URL als Argument an diesen Host. Der Server nimmt es von dort. Beachten Sie, dass dieser Prozess bedeutet, dass die Formulardaten auf ASCII-Codes beschränkt sind. Besondere Sorgfalt sollte darauf verwendet werden, andere Zeichentypen zu codieren und zu decodieren, wenn sie im ASCII-Format über die URL geleitet werden.

Durch das Senden eines Formulars mit METHOD = "POST" wird eine POST-Anforderung gesendet, die den Wert des Aktionsattributs und eine Nachricht verwendet, die gemäß dem durch das Attribut enctype angegebenen Inhaltstyp erstellt wurde .

Vor-und Nachteile

Da Formulardaten als Teil der URL gesendet werden, wenn GET verwendet wird -

  • Formulardaten sind auf ASCII-Codes beschränkt. Besondere Sorgfalt sollte darauf verwendet werden, andere Zeichentypen zu codieren und zu decodieren, wenn sie im ASCII-Format über die URL geleitet werden. Auf der anderen Seite können Binärdaten, Bilder und andere Dateien über METHOD = "POST" gesendet werden.
  • Alle ausgefüllten Formulardaten sind in der URL sichtbar. Darüber hinaus wird es auch im Webbrowser-Verlauf / in den Protokollen des Benutzers für den Browser gespeichert. Diese Probleme machen GET 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, um das Ausfüllen des Formulars vollständig zu umgehen.
  • Es gibt eine Einschränkung, wie viele Formulardaten gesendet werden können, da die URL-Längen begrenzt sind.
  • Skriptkinder können Schwachstellen im System leichter aufdecken, um sie zu hacken. Zum Beispiel wurde Citibank gehackt, indem Kontonummern in der URL-Zeichenfolge geändert wurden. [1] Natürlich können erfahrene Hacker oder Webentwickler solche Sicherheitslücken aufdecken, selbst wenn POST verwendet wird. es ist nur ein bisschen schwieriger. Im Allgemeinen muss der Server gegenüber vom Client gesendeten Daten misstrauisch sein und sich vor unsicheren direkten Objektreferenzen schützen.

Unterschiede in der serverseitigen Verarbeitung

Grundsätzlich hängt die Verarbeitung der übermittelten Formulardaten davon ab, ob sie mit METHOD = "GET" oder METHOD = "POST" gesendet werden. Da die Daten auf unterschiedliche Weise codiert werden, sind unterschiedliche Decodierungsmechanismen erforderlich. Daher kann das Ändern der METHODE im Allgemeinen eine Änderung des Skripts erfordern, das die Übermittlung verarbeitet. Wenn Sie beispielsweise die CGI-Schnittstelle verwenden, empfängt das Skript die Daten in einer Umgebungsvariablen (QUERYSTRING), wenn GET verwendet wird. Wenn jedoch POST verwendet wird, werden Formulardaten im Standardeingabestream ( stdin ) übergeben, und die Anzahl der zu lesenden Bytes wird durch den Header für die Inhaltslänge 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 betreffen. Eine andere Perspektive ist, dass mehrere idempotente Abfragen den gleichen Effekt haben wie eine einzelne Abfrage. Wenn Datenbankaktualisierungen oder andere Aktionen wie das Auslösen von E-Mails erforderlich sind, wird die Verwendung von POST empfohlen.

Aus dem Dropbox-Entwicklerblog:

Ein Browser weiß nicht genau, was ein bestimmtes HTML-Formular tut. Wenn das Formular jedoch über HTTP GET gesendet wird, weiß der Browser, dass es sicher ist, die Übermittlung automatisch zu wiederholen, wenn ein Netzwerkfehler vorliegt. Bei Formularen, die HTTP POST verwenden, ist ein erneuter Versuch möglicherweise nicht sicher, sodass der Browser den Benutzer zuerst um Bestätigung bittet.

Eine "GET" -Anforderung kann häufig zwischengespeichert werden, während eine "POST" -Anforderung kaum zwischengespeichert werden 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 wird die Verwendung von POST auch für idempotente Abfragen empfohlen:

  • Wenn die Formulardaten Nicht-ASCII-Zeichen enthalten würden (z. B. Zeichen mit Akzent), ist METHOD = "GET" im Prinzip nicht anwendbar, obwohl dies in der Praxis möglicherweise funktioniert (hauptsächlich für ISO Latin 1-Zeichen).
  • Wenn der Formulardatensatz groß ist - beispielsweise Hunderte von Zeichen -, kann METHOD = "GET" praktische Probleme bei Implementierungen verursachen, die diese langen URLs nicht verarbeiten können.
  • Möglicherweise möchten Sie METHOD = "GET" vermeiden, um Benutzern die Sichtbarkeit des Formulars zu verringern, insbesondere um "versteckte" Felder (INPUT TYPE = "HIDDEN") versteckter zu machen, indem sie nicht in der URL angezeigt werden. Aber selbst wenn Sie versteckte Felder mit METHOD = "POST" verwenden, werden diese weiterhin im HTML-Quellcode angezeigt.

Was ist mit HTTPS?

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

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

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

Angenommen, Ihre Internetverbindung wird überwacht. Welche Informationen zu dieser Anfrage 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, sind dem Angreifer, der Ihren Webverkehr überwacht, nur die folgenden Informationen bekannt:

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

Der Pfadteil der URL - dh die tatsächlich angeforderte Seite sowie die Parameter der Abfragezeichenfolge - sind geschützt (verschlüsselt), während sie sich "über das Kabel" befinden, dh auf dem Weg zum Zielserver sind. Bei POST-Anfragen ist die Situation genau die gleiche.

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

Ähnlicher Artikel