Holen Sie sich vs. POST

Holen Sie sich vs. POST

Http POST Anfragen liefern zusätzliche Daten vom Client (Browser) dem Server in der Nachrichtenbehörde. Im Gegensatz, ERHALTEN Anfragen enthalten alle erforderlichen Daten in der URL. Formulare in HTML können eine der beiden Methoden durch Angeben verwenden method = "post" oder method = "get" (Standard) in der Element. Die angegebene Methode bestimmt, wie Formulardaten an den Server übermittelt werden. Wenn die Methode erhalten ist, werden alle Formulardaten in die URL codiert, die an die angehängt sind Aktion URL als Abfrage -Zeichenfolgenparameter. Bei Post werden Formulardaten im Nachrichtenteil der HTTP -Anfrage angezeigt.

Vergleichstabelle

Holen Sie sich versus Vergleichstabelle
ERHALTENPOST
  • Die aktuelle Bewertung beträgt 4.12/5
  • 1
  • 2
  • 3
  • 4
  • 5
(1244 Bewertungen)
  • Die aktuelle Bewertung beträgt 4.42/5
  • 1
  • 2
  • 3
  • 4
  • 5
(1364 Bewertungen)
Geschichte Parameter bleiben in der Browsergeschichte, weil sie Teil der URL sind Parameter werden in der Browsergeschichte nicht gespeichert.
Mit einem Lesezeichen versehen Kann mit einem Lesezeichen versehen werden. Kann nicht mit einem Lesezeichen versehen werden.
Rückknopf/Verhalten neu GET-Anforderungen werden erneut ausgeführt, werden jedoch möglicherweise nicht wieder auf den Server eingereicht, wenn der HTML im Browser-Cache gespeichert ist. Der Browser benachrichtigt den Benutzer normalerweise darüber, dass Daten erneut eingereicht werden müssen.
Codierungstyp (EngeTepe -Attribut) Anwendung/x-www-form-urlencoded Multipart/Form-Daten oder Anwendung/X-WWW-Form-Urlencoded verwenden Sie mehrteilige Codierung für binäre Daten.
Parameter kann senden, aber die Parameterdaten sind auf das beschränkt, was wir in die Anforderungszeile (URL) einstellen können. Sicherlich sind einige Server mit weniger als 2 kk Parameter bis zu 64.000 Handlungen zu verhandeln Kann Parameter, einschließlich Hochladen von Dateien, an den Server senden.
Gehackt Einfacher zu hacken für Skriptkinder Schwieriger zu hacken
Einschränkungen des Formulardatentyps Ja, nur ASCII -Zeichen erlaubt. Keine Einschränkungen. Binärdaten sind ebenfalls erlaubt.
Sicherheit Get ist weniger sicher im Vergleich zu Post, da die gesendeten Daten Teil der URL sind. Es wird also in Browser -Verlaufs- und Serverprotokollen in PlainText gespeichert. Der Beitrag ist etwas sicherer als erhalten, da die Parameter nicht im Browserverlauf oder in Webserverprotokollen gespeichert sind.
Einschränkungen der Formulardatenlänge Ja, da Formdaten in der URL liegen und die URL -Länge eingeschränkt ist. Eine sichere URL -Längengrenze beträgt häufig 2048 Zeichen, variiert jedoch je nach Browser und Webserver. Keine Einschränkungen
Benutzerfreundlichkeit GET -Methode sollte nicht verwendet werden, wenn Sie Passwörter oder andere vertrauliche Informationen senden. Post -Methode, die beim Senden von Passwörtern oder anderen vertraulichen Informationen verwendet wird.
Sichtweite GET -Methode ist für alle sichtbar (sie wird in der Adressleiste des Browsers angezeigt) und hat Grenzen für die Sendungsmenge. Postmethodenvariablen werden in der URL nicht angezeigt.
Zwischengespeichert Kann zwischengespeichert werden Nicht zwischengespeichert

Unterschiede bei der Einreichung von Form

Der grundlegende Unterschied zwischen Method = "get" Und Method = "post" ist, dass sie entsprechen Verschiedene HTTP -Anfragen, wie in den HTTP -Spezifikationen definiert. Der Einreichungsprozess für beide Methoden beginnt auf die gleiche Weise - ein Formulardatensatz wird vom Browser konstruiert und dann auf eine durch die angegebene Weise codiert Enctype Attribut. Für Method = "post Die Enctype Attribut kann sein Mehrpartikel/Formdaten oder Anwendung/x-www-form-urlencoded, wohingegen für Method = "get", nur Anwendung/x-www-form-urlencoded ist erlaubt. Dieser Formulardatensatz wird dann an den Server übertragen.

Für die Einreichung von Formular mit method = "get" konstruiert der Browser eine URL, indem der Wert des Aktion Attribut anhängen a ? Anschließend den Formulardatensatz anhängen (codiert mit der Anwendung/x-www-form-urlencoded Inhaltstyp). Der Browser verarbeitet diese URL dann, als würde man einem Link folgen (oder als hätte der Benutzer die URL direkt eingegeben). Der Browser unterteilt die URL in Teile und erkennt einen Host, sendet dann an diesen Host eine Get -Anfrage mit dem Rest der URL als Argument. Der Server nimmt es von dort aus. Beachten Sie, dass dieser Prozess bedeutet, dass die Formulardaten auf ASCII -Codes beschränkt sind. Besonderes Sorgfalt sollte darauf geachtet werden, andere Arten von Zeichen zu codieren und zu dekodieren, wenn sie im ASCII -Format durch die URL geleitet werden.

Die Einreichung eines Formulars mit Methode = "Post" führt dazu, dass eine Postanforderung gesendet wird, wobei der Wert des Aktion Attribut und eine Nachricht, die gemäß dem von der von der angegebenen Inhaltstyp erstellt wurde Enctype Attribut.

Vor-und Nachteile

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

  • Formulardaten sind auf ASCII -Codes beschränkt. Besonderes Sorgfalt sollte darauf geachtet werden, andere Arten von Zeichen zu codieren und zu dekodieren, wenn sie im ASCII -Format durch die URL geleitet werden. Andererseits können Binärdaten, Bilder und andere Dateien alle über eingereicht werden Method = "post"
  • Alle ausgefüllten Formdaten sind in der URL sichtbar. Darüber hinaus wird es auch im Webbrowsing/-protokollen des Benutzers für den Browser gespeichert. Diese Probleme machen ERHALTEN weniger sicher.
  • Ein Vorteil von Formulardaten, die als Teil der URL gesendet werden.
  • Es gibt eine Einschränkung, wie viel Formular Daten gesendet werden können, da die URL -Längen begrenzt sind.
  • Skriptkiddies können leichter Schwachstellen im System aufdecken, um es zu hacken. Zum Beispiel wurde die Citibank gehackt, indem die Kontonummern in der URL -Zeichenfolge geändert werden.[1] Natürlich können erfahrene Hacker oder Webentwickler solche Schwachstellen aufdecken, auch wenn Post verwendet wird. Es ist nur ein bisschen schwieriger. Im Allgemeinen muss der Server den vom Client gesendeten Daten misstrauisch sein und sich gegen unsichere direkte Objektreferenzen bewachen.

Unterschiede in der serverseitigen Verarbeitung

Im Prinzip hängt die Verarbeitung eines eingereichten Formulardaten davon ab, ob sie mit gesendet werden Method = "get" oder Method = "post". Da die Daten auf unterschiedliche Weise codiert werden, sind unterschiedliche Dekodierungsmechanismen erforderlich. Im Allgemeinen kann das Ändern der Methode eine Änderung des Skripts erfordern, das die Einreichung verarbeitet. Bei der Verwendung der CGI -Schnittstelle empfängt das Skript beispielsweise die Daten in einer Umgebungsvariablen (QueryString), wenn ERHALTEN wird eingesetzt. Aber wenn POST wird verwendet, Formulardaten werden im Standardeingangsstrom übergeben (Stdin) und die Anzahl der zu gelesenen Bytes wird durch den Header der Inhaltslänge angegeben.

Was passiert beim Get -und -post -Variablenkonflikt?

In einigen Sprachen wie PHP werden die Informationen von GET und Post -Parametern zusätzlich auch separat verfügbar sein.G., $ _Request in PHP. Wenn es einen Konflikt gibt-i.e., Der gleiche Parameter Name wird mit unterschiedlichen Werten in GET verwendet und nach dem Konflikt wird mit bestimmten Regeln gelöst. Im Fall von PHP wird Vorrang von der entschieden variablen_order Konfigurationsrichtlinie. Die Standardreihenfolge ist EGPCS (Umgebung, Get, Post, Cookie, Server). Dies bedeutet.

Empfohlene Nutzung

Get wird empfohlen, wenn "idempotent" Formulare einreicht - diejenigen, die den Zustand der Welt nicht wesentlich verändern ". Mit anderen Worten, Formen, die nur Datenbankabfragen beinhalten. Eine weitere Perspektive ist, dass mehrere idempotente Abfragen den gleichen Effekt haben wie eine einzige Abfrage. Wenn Datenbankaktualisierungen oder andere Aktionen wie Auslösen von E -Mails beteiligt sind, wird die Verwendung von Post empfohlen.

Aus dem Dropbox Developer -Blog:

Ein Browser weiß nicht genau, was ein bestimmtes HTML -Formular tut. Wenn das Formular jedoch über HTTP -GET eingereicht wird, weiß der Browser, dass es sicher ist, die Einreichung automatisch wiederzuholen, wenn ein Netzwerkfehler vorliegt. Für Formulare, die HTTP -Post verwenden, ist es möglicherweise nicht sicher, wieder vorzunehmen.

Eine "Get" -Anfrage ist oft zwischengespeichert, während eine "Post" -Anfrage kaum sein kann. Für Abfragesysteme kann dies eine erhebliche Effizienzwirkung haben, insbesondere wenn die Abfragebräge einfach sind, da Caches möglicherweise die häufigsten Abfragen dienen.

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

  • Wenn die Formulardaten Nicht-ASCII-Zeichen enthalten würden (wie akzentuelle Zeichen), dann Method = "get" ist grundsätzlich unanwendbar, obwohl es in der Praxis funktioniert (hauptsächlich für ISO -Latein 1 -Zeichen).
  • Wenn der Formulardatensatz groß ist - Sagen Sie, dann Hunderte von Charakteren - dann Method = "get" kann praktische Probleme mit Implementierungen verursachen, die diese langen URLs nicht bewältigen können.
  • Sie möchten vielleicht vermeiden Method = "get" Um es den Benutzern weniger sichtbar zu machen, wie das Formular funktioniert, insbesondere um "versteckte" Felder (Eingabetyp = "Hidden") mehr versteckt zu machen, indem sie nicht in der URL erscheinen. Aber selbst wenn Sie versteckte Felder mit verwenden Method = "post", Sie werden immer noch im HTML -Quellcode erscheinen.

Was ist mit Https??

Aktualisiert am 15. Mai 2015: Insbesondere bei Verwendung von HTTPS (HTTP Over TLS/SSL) bietet Post -Angebot mehr Sicherheit als erhalten, als zu bekommen?

Dies ist eine interessante Frage. Sagen Sie, Sie stellen eine Anfrage an eine Webseite ein:

 Holen Sie sich https: // www.Beispiel.com/Login.Php?user = mickey & passwd = mini 

Unter der Annahme, dass Ihre Internetverbindung überwacht wird, welche Informationen zu dieser Anfrage dem Snooper zur Verfügung stehen? Wenn stattdessen Post verwendet wird und die Benutzer- und PASSWD -Daten in Postvariablen enthalten sind, wird dies bei HTTPS -Verbindungen sicherer?

Die Antwort ist nein. Wenn Sie eine solche Get -Anfrage stellen, sind nur die folgenden Informationen dem Angreifer bekannt, der Ihren Webverkehr überwacht:

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

Der Pfad Teil der URL - ich.e., Die tatsächliche aufforderte Seite sowie die Parameter der Abfragestöne sind geschützt (verschlüsselt), während sie "über dem Draht" i sind.e., auf dem Weg zum Zielserver auf dem Weg zum Zielserver. Die Situation ist genau für Postanfragen gleich.

Der POST Die Methode behält jedoch auch bei HTTPS einen Vorteil, jedoch. Webserver neigen dazu, die gesamte angeforderte URL in Klartext in ihren Zugriffsprotokollen zu protokollieren. Das Senden sensibler Informationen über Get ist also keine gute Idee. Dies gilt unabhängig davon, ob HTTP oder HTTPS verwendet wird.