Baseline Widely available
Die POST HTTP-Methode sendet Daten an den Server. Der Typ des Anfragetextes wird durch den Content-Type-Header angegeben.
Der Unterschied zwischen PUT und POST ist, dass PUT idempotent ist: Ein einmaliger Aufruf unterscheidet sich nicht von mehreren aufeinanderfolgenden Aufrufen (es gibt keine Seiteneffekte). Aufeinanderfolgende identische POST-Anfragen können zusätzliche Effekte haben, wie etwa dass die gleiche Bestellung mehrmals erstellt wird.
HTML-Formulare senden typischerweise Daten unter Verwendung von POST, was normalerweise zu einer Ãnderung auf dem Server führt. Für HTML-Formulare wird das Format/die Kodierung des Anfragetextes durch das enctype-Attribut des <form>-Elements oder des formenctype-Attributs der <input> oder <button>-Elemente bestimmt. Die Kodierung kann eine der folgenden sein:
application/x-www-form-urlencoded: Die Schlüssel und Werte werden in Schlüssel-Wert-Tupeln kodiert, die durch ein kaufmännisches Und-Zeichen (&) getrennt sind, mit einem Gleichheitszeichen (=) zwischen dem Schlüssel und dem Wert (z. B. first-name=Frida&last-name=Kahlo). Nicht-alphanumerische Zeichen in sowohl Schlüsseln als auch Werten werden prozentkodiert: Dies ist der Grund, warum dieser Typ nicht geeignet ist, um mit Binärdaten verwendet zu werden, und multipart/form-data hierfür genutzt werden sollte.multipart/form-data: Jeder Wert wird als Datenblock (âBody-Partâ) gesendet, mit einem von der Benutzer-Agent definierten Trennzeichen (zum Beispiel boundary="delimiter12345") zur Trennung jedes Teils. Die Schlüssel werden im Content-Disposition-Header eines jeden Teils oder Datenblocks beschrieben.text/plainWenn die POST-Anfrage nach einem fetch()-Aufruf gesendet wird oder aus einem anderen Grund als einem HTML-Formular, kann der Anfragetext jeglicher Typ sein. Wie in der HTTP 1.1-Spezifikation beschrieben, ist POST so konzipiert, dass eine einheitliche Methode für die folgenden Funktionen bereitgestellt wird:
POST <request-target>["?"<query>] HTTP/1.1
<request-target>
Identifiziert die Zielressource der Anfrage, wenn sie mit den im Host-Header bereitgestellten Informationen kombiniert wird. Dies ist ein absoluter Pfad (z. B. /path/to/file.html) in Anfragen an einen Ursprungsserver und eine absolute URL in Anfragen an Proxies (z. B. http://www.example.com/path/to/file.html).
<query> Optional
Eine optionale Abfragekomponente, die durch ein Fragezeichen ? eingeleitet wird. Häufig verwendet, um Identifikationsinformationen in Form von key=value-Paaren zu übermitteln.
Ein Formular, das die application/x-www-form-urlencoded-Kodierung verwendet (die Standardeinstellung), sendet eine Anfrage, bei der der Textkörper die Formulardaten in key=value-Paaren enthält, wobei jedes Paar durch ein &-Symbol getrennt ist, wie unten gezeigt:
POST /test HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
field1=value1&field2=value2
Die multipart/form-data-Kodierung wird verwendet, wenn ein Formular Dateien oder eine groÃe Menge an Daten enthält. Dieser Anfragetext trennt jeden Teil des Formulars durch eine Grenzzeichenfolge. Ein Beispiel für eine Anfrage in diesem Format:
POST /test HTTP/1.1
Host: example.com
Content-Type: multipart/form-data;boundary="delimiter12345"
--delimiter12345
Content-Disposition: form-data; name="field1"
value1
--delimiter12345
Content-Disposition: form-data; name="field2"; filename="example.txt"
value2
--delimiter12345--
Der Content-Disposition-Header gibt an, wie die Formulardaten verarbeitet werden sollen, indem das Feld name und gegebenenfalls filename spezifiziert wird.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3