Beitrag: Senden Sie die zu verarbeitenden Daten an die angegebene Ressource. Die Datenlänge ist unbegrenzt, kann nicht zwischengespeichert werden, kann nicht im Browserverlauf gespeichert werden und ist äußerst sicher. POST ist stabiler und zuverlässiger als GET.
1. Gemäß der HTTP-Spezifikation wird GET zur Informationsbeschaffung verwendet und sollte sicher und idempotent sein.
(1) Der sogenannte Safe bedeutet, dass der Vorgang zum Erhalten von Informationen und nicht zum Ändern von Informationen verwendet wird. Mit anderen Worten: GET-Anfragen sollten im Allgemeinen keine Nebenwirkungen haben. Das heißt, es werden nur Ressourceninformationen abgerufen, genau wie bei einer Datenbankabfrage. Es werden keine Daten geändert oder hinzugefügt und der Status der Ressource wird nicht beeinflusst.
* 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 zurückgeben sollten. Hier erkläre ich das Konzept der Idempotenz noch einmal:
Idempotenz (Idempotent, Idempotenz) ist ein mathematisches oder informatisches Konzept, das in der abstrakten Algebra üblich ist.
Es gibt mehrere Definitionen von Idempotenz:
Wenn bei unären Operationen eine Operation mehrmals für alle Zahlen im Bereich ausgeführt wird, ist das Ergebnis, das durch mehrmaliges Ausführen der Operation erhalten wird, dasselbe wie das Ergebnis, das durch Ausführen von erhalten wird Operation einmal, dann sagen wir, dass die Operation idempotent ist. Ein Beispiel ist die Absolutwertarithmetik in der Menge der reellen Zahlen: abs(a)=abs(abs(a)).
Für binokulare Operationen ist es erforderlich, dass die Operation ausgeführt wird, wenn die beiden an der Operation beteiligten Werte gleich sind und das Operationsergebnis gleich den beiden an der Operation beteiligten Werten ist idempotent sein, beispielsweise den Wert zweier Zahlen ermitteln Die Funktion des Maximalwerts ist in der Menge der reellen Zahlen idempotent, dh max(x,x) = x.
Nachdem Sie die obige Erklärung gelesen haben, sollten Sie in der Lage sein, die Bedeutung von GET idempotent zu verstehen.
Aber in der tatsächlichen Anwendung sind die beiden oben genannten Vorschriften nicht so streng. Beispiele für das Zitieren von Artikeln anderer Personen: Beispielsweise wird die Titelseite einer Nachrichtenseite ständig aktualisiert. Obwohl die zweite Anfrage einen anderen Nachrichtenstapel zurückgibt, gilt der Vorgang dennoch als sicher und idempotent, da er immer die aktuellen Nachrichten zurückgibt. Grundsätzlich gilt: Wenn das Ziel darin besteht, dass der Nutzer beim Öffnen eines Links sicher sein kann, dass sich die Ressource aus seiner Sicht nicht verändert hat.
2. Gemäß der HTTP-Spezifikation stellt POST eine Anfrage dar, die Ressourcen auf dem Server ändern kann. Um das obige Beispiel weiter zu zitieren: Nehmen wir die Nachrichten-Website als Beispiel. Leserkommentare zu den Nachrichten sollten über POST implementiert werden, da die Ressourcen der Website nach der Übermittlung der Kommentare unterschiedlich sind oder geändert werden.
Oben wird kurz auf einige grundlegende Probleme von GET und POST in der HTTP-Spezifikation eingegangen. In der Praxis befolgen jedoch viele Menschen die HTTP-Spezifikationen nicht. Es gibt viele Gründe für dieses Problem, wie zum Beispiel: 1. Viele Menschen sind gierig nach Bequemlichkeit und verwenden GET, wenn sie Ressourcen aktualisieren, weil POST verwenden , müssen Sie zum FORM (Formular) gehen, was etwas mühsam sein wird.
2. Das Hinzufügen, Löschen, Ändern und Überprüfen von Ressourcen kann tatsächlich über GET/POST erfolgen, und es ist nicht erforderlich, PUT und DELETE zu verwenden.
3. Ein weiterer Grund ist, dass die frühen Web-MVC-Framework-Designer URLs nicht bewusst als abstrakte Ressourcen behandelten und gestalteten. Ein schwerwiegenderes Problem besteht daher darin, dass das traditionelle Web-MVC-Framework grundsätzlich beide nur die beiden HTTP-Methoden GET unterstützt und POST, jedoch nicht die PUT- und DELETE-Methoden.
* Erklären Sie kurz MVC: MVC war ursprünglich im Desktop-Programm vorhanden. M bezieht sich auf das Datenmodell, V bezieht sich auf die Benutzeroberfläche und C bezieht sich auf den Controller. Der Zweck der Verwendung von MVC besteht darin, die Implementierungscodes von M und V zu trennen, sodass dasselbe Programm unterschiedliche Darstellungen verwenden kann.
Die oben genannten drei Punkte beschreiben typischerweise den alten Stil (der sich nicht strikt an die HTTP-Spezifikation hält). Mit der Entwicklung der Architektur erscheint nun REST (Representational State Transfer), ein neuer Stil, der HTTP unterstützt Dies ist nicht der Fall. Weitere Informationen finden Sie unter „RESTful Web Services“.
Nachdem wir über die Hauptprobleme gesprochen haben, schauen wir uns den Unterschied zwischen GET und POST von der Oberfläche aus an:
1. Die von GET angeforderten Daten werden angehängt URL Danach (d. h. Platzieren der Daten im HTTP-Protokoll-Header) teilen Sie die URL und die Übertragungsdaten mit ? auf und verbinden die Parameter mit &, wie zum Beispiel: login.action?name=hyddd&password=idontknow&verify=%E4%BD %A0%E5%A5 %BD. Wenn es sich bei den Daten um englische Buchstaben/Zahlen handelt, senden Sie sie unverändert. Wenn es sich um ein Leerzeichen handelt, verschlüsseln Sie die Zeichenfolge direkt mit BASE64, und Sie erhalten etwas wie: %E4 %BD%A0%E5%A5% BD, wobei XX in %XX die ASCII-Darstellung des Symbols im Hexadezimalformat ist.
POST platziert die übermittelten Daten im Hauptteil des HTTP-Pakets.
2. „Die mit der GET-Methode übermittelten Daten können nur bis zu 1024 Byte groß sein. Theoretisch gibt es keine Begrenzung für POST, das eine größere Datenmenge übertragen kann. Das Maximum beträgt 80 KB in IIS4 und 100 KB in IIS5"? ? !
Ich habe den obigen Satz aus einem anderen Artikel übernommen. Tatsächlich ist es falsch und ungenau, Folgendes zu sagen:
(1) Erstens: „Die von GET übermittelten Daten können nur bis zu 1024 Bytes umfassen.“ Da GET Daten über eine URL übermittelt, hängt die Datenmenge, die von GET übermittelt werden kann, direkt von der Länge ab die URL. Tatsächlich gibt es keine obere Parameterbeschränkung für URLs und die HTTP-Protokollspezifikation begrenzt die URL-Länge nicht. Dieses Limit wird von bestimmten Browsern und Servern vorgegeben. Die URL-Längenbeschränkung des IE beträgt 2083 Byte (2K+35). Für andere Browser wie Netscape, FireFox usw. gibt es theoretisch keine Längenbeschränkung und die Begrenzung hängt von der Unterstützung des Betriebssystems ab.
Beachten Sie, dass es sich bei diesem Limit um die gesamte URL-Länge handelt, nicht nur um die Länge Ihrer Parameterwertdaten. [Siehe Referenz 5]
(2) Theoretisch gibt es keine Größenbeschränkung für POST, und die HTTP-Protokollspezifikation legt keine Größenbeschränkung fest die Menge der POST-Daten". Ungenau, es gibt keine Begrenzung für POST-Daten. Was die Einschränkung darstellt, ist die Verarbeitungsleistung des Server-Handlers.
Für ASP-Programme gilt für das Request-Objekt bei der Verarbeitung jedes Formularfelds eine Datenlängenbeschränkung von 100 KB. Wenn Sie jedoch Request.BinaryRead verwenden, gibt es keine solche Einschränkung.
Darüber hinaus hat Microsoft für IIS 6.0 die Einschränkungen aus Sicherheitsgründen erhöht. Wir müssen auch auf Folgendes achten:
1). Das Standard-ASP-POST-Datenvolumen von IIS 6.0 beträgt 200 KB und die Grenze jedes Formularfelds beträgt 100 KB.
2).Die standardmäßige maximale Größe hochgeladener Dateien in IIS 6.0 beträgt 4 MB.
3).Der standardmäßige maximale Anforderungsheader von IIS 6.0 beträgt 16 KB.
Vor IIS 6.0 gab es solche Einschränkungen nicht. [Siehe Referenz 5]
Die oben genannten 80 KB und 100 KB sind möglicherweise nur die Standardwerte (Hinweis: Ich habe die Parameter von IIS4 und IIS5 nicht bestätigt), aber sie können definitiv von Ihnen selbst festgelegt werden. Da jede IIS-Version unterschiedliche Standardwerte für diese Parameter hat, lesen Sie bitte die entsprechende IIS-Konfigurationsdokumentation für Einzelheiten.
3. In ASP verwendet der Server Request.QueryString, um GET-Anfrageparameter abzurufen, und Request.Form, um POST-Anfrageparameter abzurufen. Verwenden Sie in JSP request.getParameter("XXXX"), um es abzurufen. Obwohl es in JSP auch eine request.getQueryString()-Methode gibt, ist deren Verwendung problematischer. Beispiel: Übergeben Sie ein test.jsp?name=hyddd&password= hyddd, verwenden Sie request. getQueryString() erhält: name=hyddd&password=hyddd. In PHP können Sie $_GET und $_POST verwenden, um Daten in GET bzw. POST abzurufen, während $_REQUEST Daten sowohl in GET- als auch in POST-Anfragen abrufen kann. Es ist erwähnenswert, dass die Verwendung von request in JSP und $_REQUEST in PHP versteckte Gefahren birgt. Ich werde das nächste Mal eine Artikelzusammenfassung schreiben.
4. POST ist sicherer als GET. Hinweis: Die hier erwähnte Sicherheit ist nicht dasselbe Konzept wie die oben in GET erwähnte „Sicherheit“. Die Bedeutung von „Sicherheit“ oben bedeutet nur, dass keine Datenänderung vorgenommen wird, und die Bedeutung von Sicherheit ist hier die wahre Bedeutung von Sicherheit. Beispiel: Bei der Übermittlung von Daten über GET werden der Benutzername und das Passwort im Klartext auf der URL angezeigt , weil (1) die Anmeldeseite möglicherweise im Browser-Cache liegt, (2) andere Personen den Browserverlauf anzeigen und dann Ihr Konto und Ihr Kennwort erhalten können. Darüber hinaus kann die Verwendung von GET zum Übermitteln von Daten auch zu Cross-Site-Request-Forgery-Angriffen führen.
Zusammenfassend ist „Get“ eine Anforderung an den Server, während „Post“ eine Anforderung zum Senden von Daten an den Server ist. In FORM (Formular) ist die Methode im Wesentlichen „GET“ und „ POST hat nur unterschiedliche Sendemechanismen, nicht einer wird genommen und der andere wird gesendet!
Das obige ist der detaillierte Inhalt vonAnalysieren Sie den Unterschied zwischen Post- und Get-Anfragen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!