HTTP definiert verschiedene Möglichkeiten, mit dem Server zu interagieren, und es gibt vier grundlegende Methoden, nämlich GET, POST, PUT und DELETE. Der vollständige Name der URL ist ein Ressourcenbeschreiber, wir können ihn uns so vorstellen: eine URL-Adresse, sie wird verwendet, um eine Ressource in einem Netzwerk zu beschreiben, und GET, POST, PUT, DELETE in HTTP entspricht den vier Operationen des Überprüfens, Modifizierens, Hinzufügens und Löschens dieser Ressource. An diesem Punkt sollten Sie ein allgemeines Verständnis haben: GET wird meist verwendet, um Ressourceninformationen zu erhalten/abzufragen, während POST meist zur Aktualisierung von Ressourceninformationen verwendet wird.
1. Laut der HTTP-Spezifikation wird GET für die Informationsabfrage verwendet und sollte sicher und idempotent sein.
(1). Die sogenannte Sicherheit bedeutet, dass die Operation dazu dient, Informationen zu erhalten und nicht zu ändern. Mit anderen Worten: GET-Anfragen sollten im Allgemeinen keine Nebenwirkungen haben. Das heißt, es erhält nur Ressourceninformationen, ähnlich wie Datenbankanfragen, und verändert keine Daten, fügt keine Daten hinzu und beeinflusst den Zustand der Ressource nicht.
* Hinweis: Die Bedeutung von Sicherheit bezieht sich hier nur auf nicht veränderte Informationen.
(2). Idempotent bedeutet, dass mehrere Anfragen an dieselbe URL dasselbe Ergebnis liefern sollten.
In der praktischen Anwendung sind die oben genannten beiden Vorschriften jedoch nicht so streng. Beispiele für das Zitieren von Artikeln anderer: Zum Beispiel wird die Startseite einer Nachrichtenseite ständig aktualisiert. Obwohl die zweite Anfrage eine andere Nachrichtensendung zurückgibt, gilt die Operation dennoch als sicher und idempotent, da sie immer die aktuellen Nachrichten zurückgibt. Grundsätzlich gilt: Wenn das Ziel ist, dass ein Nutzer beim Öffnen eines Links sicher sein kann, dass die Ressource aus seiner Sicht nicht verändert wurde.
2. Laut der HTTP-Spezifikation stellt POST eine Anfrage dar, die eine Ressource auf dem Server verändern kann. Um das obige Beispiel weiter zu zitieren: Still news. Nehmen wir die Website als Beispiel, sollten Leser eigene Kommentare zu den Nachrichten abgeben, da die Ressourcen der Seite nach dem Absenden des Kommentars oder der Änderung der Ressourcen anders sind.
Das Obige behandelt grob einige der Prinzipien von GET und POST in der HTTP-Spezifikation. Allerdings befolgen viele Menschen die HTTP-Spezifikation nicht, wenn sie es tatsächlich tun, was zu vielen Gründen für dieses Problem führen kann, zum Beispiel:
1. Viele Menschen nutzen GET, um Ressourcen zu aktualisieren, weil sie zu FORM gehen müssen, um POST zu nutzen, was etwas umständlich sein wird.
2. Das Hinzufügen, Löschen, Ändern und Überprüfen von Ressourcen kann tatsächlich über GET/POST durchgeführt werden, ohne dass PUT und DELETE verwendet werden müssen.
3. Ein weiteres Beispiel ist, dass frühe Web-MVC-Framework-Designer URLs nicht bewusst als abstrakte Ressourcen behandelten und gestalteten, sodass ein ernstes Problem darin besteht, dass das traditionelle Web MVC-Framework im Grunde nur zwei HTTP-Methoden, GET und POST, unterstützt, aber keine PUT- und DELETE-Methoden.
* Eine kurze Erklärung von MVC: MVC existierte ursprünglich im Desktop-Programm, M steht für das Datenmodell, V für die Benutzeroberfläche und C für den Controller. Der Zweck der Verwendung von MVC ist es, den Implementierungscode von M und V zu trennen, sodass dasselbe Programm unterschiedliche Darstellungen verwenden kann.
Die oben genannten drei Punkte beschreiben typischerweise den alten Stil (ohne strikte Einhaltung der HTTP-Spezifikation), mit der Entwicklung der Architektur gibt es nun REST (Representational State Transfer), einen neuen Stil, der die HTTP-Spezifikation unterstützt.
Nachdem wir über das Hauptproblem gesprochen haben, schauen wir uns den Unterschied zwischen GET und POST anhand des Oberflächenphänomens an:
1. Die Daten der GET-Anfrage werden an die URL gebunden (das heißt, die Daten werden im HTTP-Protokoll-Header platziert), und der ? Teilen Sie die URL auf und übertragen Sie die Daten, und die Parameter werden durch & verbunden, zum Beispiel: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Wenn die Daten englische Buchstaben/Zahlen sind, senden Sie sie so, wie sie sind; wenn es ein Leerzeichen ist, wandeln Sie sie in + um, wenn es chinesische/andere Zeichen sind, und verschlüsseln Sie die Zeichenkette direkt mit BASE64, um eine Probe zu erhalten, wie zum Beispiel: %E4%BD%A0%E5%A5%BD, wobei XX in %XX das ASCII ist, das durch das hexadezimale Symbol dargestellt wird.
POST legt die eingereichten Daten im Paketkörper des HTTP-Pakets.
2. "Die maximal mit der GET-Methode übermittelten Daten können nur 1024 Bytes betragen, theoretisch gibt es keine Begrenzung für POST, und eine große Datenmenge kann übertragen werden, bis zu 80 KB in IIS4 und 100 KB in IIS5"??!
Der obige Satz ist von anderen Artikeln umgeleitet, tatsächlich ist es falsch und ungenau, Folgendes zu sagen:
(1). Erstens: "Die mit der GET-Methode eingereichten Daten können höchstens 1024 Bytes betragen", weil GET Daten über eine URL übermittelt, sodass die von GET übermittelte Datenmenge direkt mit der Länge der URL zusammenhängt. Tatsächlich gibt es keine obere Parametergrenze für URLs, und die HTTP-Protokollspezifikation begrenzt die Länge der URLs nicht. Diese Begrenzung ist eine Beschränkung, die von einem bestimmten Browser und Server auferlegt wird. IEs Grenze für die URL-Länge beträgt 2083 Bytes (2K+35). Bei anderen Browsern wie Netscape, Firefox usw. gibt es keine theoretische Längenbegrenzung, und das Limit hängt von der Unterstützung des Betriebssystems ab.
Beachte, dass dies die gesamte URL-Länge begrenzt, nicht nur die Länge deines Parameterwerts. [Siehe Ref. 5]
(2). Theoretisch hat POST keine Größenbegrenzung, und die HTTP-Protokollspezifikation hat keine Größenbegrenzung, und es ist ungenau zu sagen, dass "es eine Größenbegrenzung von 80K/100K für POST-Daten gibt", und es gibt keine Begrenzung für POST-Daten, und es ist die Rechenleistung des Server-Handlers, die eine begrenzende Rolle spielt.
Für ASP-Programme hat das Request-Objekt eine Datenlängenbegrenzung von 100K bei der Verarbeitung jedes Formularfelds. Aber mit Request.BinaryRead gibt es keine solche Beschränkung.
Aus diesem Zusammenhang hat Microsoft für IIS 6.0 die Beschränkungen aus Sicherheitsgründen erhöht. Wir müssen auch auf Folgendes achten:
1). IIS 6.0 hat standardmäßig maximal 200 KB ASP POST-Daten, und die Grenze beträgt 100 KB pro Formularfeld.
2). Die Standardgröße von IIS 6.0-Upload-Dateien beträgt 4 MB.
3). IIS 6.0 hat standardmäßig einen maximalen Request-Header von 16 KB.
Diese Einschränkungen waren vor IIS 6.0 nicht verfügbar. [Siehe Ref. 5]
Die oben genannten 80K und 100K könnten also einfach die Standardwerte sein (Anmerkung: Ich habe die Parameter von IIS4 und IIS5 noch nicht bestätigt), aber du kannst sie definitiv selbst einstellen. Da die Standardwerte dieser Parameter in jeder IIS-Version unterschiedlich sind, konsultieren Sie bitte das entsprechende IIS-Konfigurationsdokument für Details.
3. Im ASP verwendet der Server Request.QueryString, um den GET-Anforderungsparameter zu erhalten, und Request.Form, um den POST-Anforderungsparameter zu erhalten. In JSP verwenden Sie request.getParameter(\"XXXX\"), um es zu erhalten, obwohl es in jsp auch eine request.getQueryString()-Methode gibt, die jedoch umständlicher ist, zum Beispiel: Senden Sie ein test.jsp?name=hyddd&password=hyddd und verwenden Sie request.getQueryString(), um :name= zu erhalten. hyddd&password=hyddd。 In PHP können Sie _GET und _POST $ verwenden, um Daten von GET bzw. POST zu erhalten, während _REQUEST $ Daten sowohl von GET- als auch POST-Anfragen erhalten können. Es ist erwähnenswert, dass es versteckte Gefahren gibt, Request in JSP und $_REQUEST in PHP zu verwenden, was beim nächsten Mal in einem Artikel zusammengefasst wird.
4.POST ist sicherer als GET. Hinweis: Die hier erwähnte Sicherheit ist nicht dasselbe Konzept wie die "Sicherheit" im obigen GET. Wenn Sie beispielsweise Daten über GET einreichen, erscheinen Ihr Benutzername und Passwort im Klartext auf der URL, weil (1) die Anmeldeseite vom Browser zwischengespeichert werden kann, (2) andere den Browserverlauf einsehen, sodass andere Ihr Konto und Passwort erhalten können Fälschungsangriff.
Zusammenfassend ist Get eine Anfrage, Daten vom Server anzufordern, während Post eine Anfrage ist, Daten an den Server zu senden; in FORM steht die Methode standardmäßig auf "GET", im Grunde sind GET und POST einfach unterschiedliche Sendemechanismen, nicht einer nimmt und schickt einen!
|
Veröffentlicht am 06.12.2014 10:54:55
|
|
|
Veröffentlicht am 07.12.2014 17:24:18
