HTTP-Request-Methoden

Schlagen Sie jede registrierte HTTP-Request-Methode nach: was sie bewirkt, welche Spezifikation sie definiert und ob sie sicher und idempotent ist. Die Tabelle umfasst die neun Kernmethoden sowie die Erweiterungen WebDAV, DeltaV und CalDAV.

Läuft lokal in deinem Browser

Kategorie ansehen: Referenz & Nachschlagen (21)

HTTP-Request-Methoden legen fest, was eine Anfrage bewirken soll. Neun Kernmethoden stammen aus HTTP selbst — GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE und PATCH; alle weiteren sind registrierte Erweiterungen für WebDAV, Versionierung und Kalender, dazu zwei Methoden, die spätere HTTP-Revisionen entfernt haben. Die Tabelle führt jede Methode des IANA-Registers für HTTP-Methoden auf, mit der definierenden Spezifikation und der Angabe, ob sie sicher und idempotent ist.

Methode	Definiert in	Sicher / idempotent	Zweck
Kernmethoden
GET	RFC 9110 §9.3.1	ja / ja	Ruft eine Darstellung der Zielressource ab.
HEAD	RFC 9110 §9.3.2	ja / ja	Ruft nur die Antwort-Header ab, ohne den Body.
POST	RFC 9110 §9.3.3	nein / nein	Sendet Daten zur Verarbeitung an die Zielressource; legt oft eine Ressource an oder stößt eine Aktion an.
PUT	RFC 9110 §9.3.4	nein / ja	Legt die Zielressource an oder ersetzt sie durch den Request-Inhalt.
DELETE	RFC 9110 §9.3.5	nein / ja	Entfernt die Zielressource.
CONNECT	RFC 9110 §9.3.6	nein / nein	Öffnet einen Tunnel zur Ziel-Authority, meist über einen Proxy.
OPTIONS	RFC 9110 §9.3.7	ja / ja	Fragt, welche Methoden und Optionen die Zielressource unterstützt.
TRACE	RFC 9110 §9.3.8	ja / ja	Lässt den Server die empfangene Anfrage zur Diagnose zurückspiegeln.
PATCH	RFC 5789 §2	nein / nein	Wendet die im Request-Inhalt beschriebenen Änderungen auf die Zielressource an.
WebDAV-Erweiterungen
PROPFIND	RFC 4918 §9.1	ja / ja	Liest die Eigenschaften einer Ressource; der Depth-Header bestimmt die Tiefe.
PROPPATCH	RFC 4918 §9.2	nein / ja	Setzt oder entfernt mehrere Eigenschaften einer Ressource in einer Anfrage.
MKCOL	RFC 4918 §9.3	nein / ja	Legt eine Collection an, die ordnerähnliche Ressource von WebDAV.
COPY	RFC 4918 §9.8	nein / ja	Kopiert eine Ressource auf den URI im Destination-Header.
MOVE	RFC 4918 §9.9	nein / ja	Verschiebt eine Ressource auf den URI im Destination-Header.
LOCK	RFC 4918 §9.10	nein / nein	Sperrt eine Ressource zum Schreiben und liefert ein Lock-Token.
UNLOCK	RFC 4918 §9.11	nein / ja	Gibt eine Sperre mit dem Token aus dem Lock-Token-Header frei.
ACL	RFC 3744 §8.1	nein / ja	Liest oder ändert die Access-Control-List einer Ressource.
SEARCH	RFC 5323 §2	ja / ja	Führt eine DASL-Abfrage über eine Collection aus und liefert die Treffer.
MKCALENDAR	RFC 4791 §5.3.1	nein / ja	Legt eine Kalender-Collection mit ihren Eigenschaften an.
BIND	RFC 5842 §4	nein / ja	Fügt eine vorhandene Ressource als neue Bindung in eine Collection ein.
UNBIND	RFC 5842 §5	nein / ja	Entfernt eine Bindung aus einer Collection.
REBIND	RFC 5842 §6	nein / ja	Verschiebt eine Bindung von einer Collection in eine andere.
ORDERPATCH	RFC 3648 §7	nein / ja	Ändert die Position der Mitglieder einer geordneten Collection.
MKREDIRECTREF	RFC 4437 §6	nein / ja	Legt eine Redirect-Reference-Ressource an, die auf einen anderen URI zeigt.
UPDATEREDIRECTREF	RFC 4437 §7	nein / ja	Ändert den Ziel-URI einer Redirect-Reference-Ressource.
Versionierungs-Erweiterungen (DeltaV)
VERSION-CONTROL	RFC 3253 §3.5	nein / ja	Stellt eine Ressource unter Versionskontrolle.
REPORT	RFC 3253 §3.6	ja / ja	Fordert einen Versions-, Eigenschafts- oder DAV-Bericht zu einer Ressource an.
CHECKOUT	RFC 3253 §8.8	nein / ja	Macht eine versionierte Ressource beschreibbar oder legt eine Working Resource an.
CHECKIN	RFC 3253 §9.4	nein / ja	Sichert die Änderungen als neue Version und setzt die Ressource wieder auf schreibgeschützt.
UNCHECKOUT	RFC 3253 §4.5	nein / ja	Bricht einen Checkout ab und verwirft die nicht gesicherten Änderungen.
MKWORKSPACE	RFC 3253 §6.3	nein / ja	Legt einen Workspace für versionierte Arbeit an.
UPDATE	RFC 3253 §7.1	nein / ja	Überträgt die Änderungen einer Version auf eine andere Ressource.
LABEL	RFC 3253 §8.2	nein / ja	Fügt Versionslabels hinzu oder entfernt sie.
MERGE	RFC 3253 §11.2	nein / ja	Führt die Unterschiede zweier Versionshistorien zusammen.
BASELINE-CONTROL	RFC 3253 §12.6	nein / ja	Macht eine Collection zu einer baseline-kontrollierten Collection.
MKACTIVITY	RFC 3253 §13.5	nein / ja	Legt eine Activity an, die Änderungen über Ressourcen hinweg bündelt.
Weitere registrierte Methoden
QUERY	RFC 10008 §2	ja / ja	Sendet eine sichere, idempotente Abfrage mit den Parametern im Request-Inhalt.
PRI	RFC 9113 §3.4	ja / ja	Wird nur im HTTP/2-Connection-Preface gesendet, vor allen Frames.
Aus HTTP entfernt
LINK	RFC 2068 §19.6.1.2	nein / ja	In RFC 2068 zum Verknüpfen von Ressourcen definiert; spätere HTTP-Revisionen haben es entfernt.
UNLINK	RFC 2068 §19.6.1.3	nein / ja	In RFC 2068 zum Lösen von Verknüpfungen definiert; spätere HTTP-Revisionen haben es entfernt.

So lesen Sie diese Methodenreferenz

Diese Seite führt jede Methode des IANA-Registers für HTTP-Methoden auf, das die IETF pflegt. Jede Zeile nennt den Methodennamen, die definierende Spezifikation, ob die Methode sicher und idempotent ist, und in einer Zeile ihre Aufgabe.

Die Zeilen sind Teil der Seite: nichts wird zur Laufzeit erzeugt, es ist keine Eingabe nötig und während des Lesens wird keine Anfrage gesendet. Das Suchfeld filtert die Tabelle nur in Ihrem Browser.

Filtern Sie die Tabelle, indem Sie einen Teil des Methodennamens, eine RFC-Nummer oder ein Wort aus der Beschreibung eingeben; der Zähler zeigt, wie viele Einträge sichtbar bleiben.

Lesen Sie die Spalte Definiert in, um zur Spezifikation zu gelangen. Das Paragrafenzeichen nennt den Abschnitt, der die Methode definiert, etwa RFC 9110 §9.3.1 für GET.

Prüfen Sie Sicher / idempotent, bevor Sie eine Anfrage wiederholen: eine sichere Methode ist als lesend definiert, eine idempotente darf mit gleicher Wirkung erneut gesendet werden.

Mit Zeile kopieren erhalten Sie die ganze Zeile, oder markieren Sie eine einzelne Zelle. Die Tabelle ist eine Referenz: nichts wird umgerechnet, gespeichert oder hochgeladen.

Was die Spalten und das Register bedeuten

Sicher und idempotent

Eine Methode ist sicher, wenn die Spezifikation sie als lesend definiert: GET, HEAD, OPTIONS, TRACE, PROPFIND, REPORT, SEARCH, QUERY und PRI sind im Register als sicher markiert. Sicher beschreibt die Absicht, nicht die Nebenwirkungen, die ein Server ergänzt — eine GET-Anfrage kann protokolliert, gezählt oder abgerechnet werden.

Eine Methode ist idempotent, wenn dieselbe Anfrage wiederholt dieselbe Wirkung hat wie einmal gesendet. PUT, DELETE und fast alle WebDAV- und DeltaV-Methoden sind idempotent; POST, PATCH, CONNECT und LOCK nicht, deshalb dürfen Client oder Proxy sie nach einem Timeout nicht automatisch wiederholen.

Das Register ist die Quelle

Die IANA aktualisiert das Register, sobald neue Methoden veröffentlicht werden, und diese Tabelle folgt ihm: Methodenname, die Flags für sicher und idempotent und die zuerst genannte Spezifikation. Führt das Register weitere Spezifikationen — MKCOL wird durch RFC 5689 erweitert, PROPFIND und REPORT durch RFC 8144 —, steht die definierende RFC in der Spalte.

Methoden außerhalb des Registers gibt es trotzdem. UPnP SSDP sendet M-SEARCH über UDP, RFC 2774 definiert Erweiterungsmethoden mit M-Präfix wie M-GET, und viele APIs erfinden eigene Verben; ein Server, der eine Methode nicht kennt, antwortet mit 405 Method Not Allowed, ein Proxy kann sie direkt ablehnen.

Entfernte und protokollspezifische Einträge

LINK und UNLINK stammen aus RFC 2068, der ersten HTTP/1.1-Spezifikation, und wurden später entfernt: das Register führt sie weiter mit ihrer Entwurfsreferenz, aber keine aktuelle HTTP-Spezifikation verwendet sie.

PRI wird einmal pro Verbindung gesendet, im HTTP/2-Connection-Preface, vor allen Frames; das Register listet außerdem die Sternchenform, die als OPTIONS * den Server als Ganzes statt einer Ressource adressiert. Beides ist in einem Request-Log leicht zu übersehen.