4. Request Methods (Anfragemethoden)

4.1. Overview (Überblick)

Das Anfragemethoden-Token ist die primäre Quelle der Anfrage-Semantik; es gibt den Zweck an, für den der Client diese Anfrage gestellt hat, und was der Client als erfolgreiches Ergebnis erwartet.

Die Semantik der Anfragemethode kann durch die Semantik einiger Header-Felder weiter spezialisiert werden, wenn diese in einer Anfrage vorhanden sind (Section 5), sofern diese zusätzlichen Semantiken nicht mit der Methode in Konflikt stehen. Beispielsweise kann ein Client bedingte Anfrage-Header-Felder (Section 5.2) senden, um die angeforderte Aktion vom aktuellen Zustand der Zielressource abhängig zu machen ([RFC7232]).

method = token

HTTP wurde ursprünglich so konzipiert, dass es als Schnittstelle zu verteilten Objektsystemen verwendet werden kann. Die Anfragemethode wurde als Anwendung von Semantik auf eine Zielressource konzipiert, ähnlich wie das Aufrufen einer definierten Methode auf einem identifizierten Objekt Semantik anwenden würde. Das Methoden-Token unterscheidet Groß- und Kleinschreibung, da es möglicherweise als Gateway zu objektbasierten Systemen mit Groß-/Kleinschreibung unterscheidenden Methodennamen verwendet wird.

Im Gegensatz zu verteilten Objekten sind die standardisierten Anfragemethoden in HTTP nicht ressourcenspezifisch, da einheitliche Schnittstellen eine bessere Sichtbarkeit und Wiederverwendbarkeit in netzwerkbasierten Systemen bieten [REST]. Einmal definiert, sollte eine standardisierte Methode dieselbe Semantik haben, wenn sie auf eine beliebige Ressource angewendet wird, obwohl jede Ressource für sich selbst bestimmt, ob diese Semantiken implementiert oder erlaubt sind.

Diese Spezifikation definiert eine Reihe standardisierter Methoden, die häufig in HTTP verwendet werden, wie in der folgenden Tabelle dargestellt. Konventionsgemäß werden standardisierte Methoden in Großbuchstaben US-ASCII definiert.

Method	Safe (Sicher)	Idempotent (Idempotent)	Description (Beschreibung)
GET	Yes	Yes	Übertragung einer aktuellen Repräsentation der Zielressource.
HEAD	Yes	Yes	Wie GET, aber nur Übertragung der Statuszeile und des Header-Abschnitts.
POST	No	No	Ressourcenspezifische Verarbeitung der Anfrage-Payload durchführen.
PUT	No	Yes	Alle aktuellen Repräsentationen der Zielressource durch die Anfrage-Payload ersetzen.
DELETE	No	Yes	Alle aktuellen Repräsentationen der Zielressource entfernen.
CONNECT	No	No	Einen Tunnel zum vom Zielressource identifizierten Server herstellen.
OPTIONS	Yes	Yes	Die Kommunikationsoptionen für die Zielressource beschreiben.
TRACE	Yes	Yes	Einen Nachrichten-Loopback-Test entlang des Pfads zur Zielressource durchführen.

Alle Allzweckserver MÜSSEN die Methoden GET und HEAD unterstützen. Alle anderen Methoden sind OPTIONAL.

Zusätzliche Methoden, die außerhalb des Geltungsbereichs dieser Spezifikation liegen, wurden für die Verwendung in HTTP standardisiert. Alle solchen Methoden sollten in der "Hypertext Transfer Protocol (HTTP) Method Registry" registriert werden, die von IANA gepflegt wird, wie in Section 8.1 definiert.

Die Menge der von einer Zielressource erlaubten Methoden kann in einem Allow-Header-Feld (Section 7.4.1) aufgelistet werden. Die Menge der erlaubten Methoden kann sich jedoch dynamisch ändern. Wenn eine Anfragemethode empfangen wird, die von einem Ursprungsserver nicht erkannt oder nicht implementiert wird, SOLLTE der Ursprungsserver mit dem Statuscode 501 (Not Implemented) antworten. Wenn eine Anfragemethode empfangen wird, die einem Ursprungsserver bekannt ist, aber für die Zielressource nicht erlaubt ist, SOLLTE der Ursprungsserver mit dem Statuscode 405 (Method Not Allowed) antworten.

4.2. Common Method Properties (Gemeinsame Methodeneigenschaften)

4.2.1. Safe Methods (Sichere Methoden)

Anfragemethoden werden als "sicher" betrachtet, wenn ihre definierte Semantik im Wesentlichen schreibgeschützt ist; d.h., der Client fordert keine Zustandsänderung auf dem Ursprungsserver an und erwartet auch keine als Ergebnis der Anwendung einer sicheren Methode auf eine Zielressource. Ebenso wird von der vernünftigen Verwendung einer sicheren Methode nicht erwartet, dass sie Schaden, Eigentumsverlust oder ungewöhnliche Belastung des Ursprungsservers verursacht.

Diese Definition sicherer Methoden hindert eine Implementierung nicht daran, Verhalten einzuschließen, das potenziell schädlich ist, nicht vollständig schreibgeschützt ist oder Nebeneffekte beim Aufrufen einer sicheren Methode verursacht. Was jedoch wichtig ist, ist, dass der Client dieses zusätzliche Verhalten nicht angefordert hat und nicht dafür verantwortlich gemacht werden kann. Beispielsweise fügen die meisten Server Anfrageinformationen am Ende jeder Antwort zu Zugriffsprotokolldateien hinzu, unabhängig von der Methode, und dies wird als sicher betrachtet, auch wenn der Protokollspeicher voll werden und den Server zum Absturz bringen könnte. Ebenso hat eine sichere Anfrage, die durch Auswahl einer Werbung im Web initiiert wird, häufig den Nebeneffekt, dass ein Werbekonto belastet wird.

Von den in dieser Spezifikation definierten Anfragemethoden sind die Methoden GET, HEAD, OPTIONS und TRACE als sicher definiert.

Der Zweck der Unterscheidung zwischen sicheren und unsicheren Methoden besteht darin, automatisierten Abrufprozessen (Spider) und Cache-Leistungsoptimierung (Vorabruf) zu ermöglichen, ohne Angst vor Schäden zu arbeiten. Darüber hinaus ermöglicht es einem User-Agent, geeignete Einschränkungen für die automatisierte Verwendung unsicherer Methoden anzuwenden, wenn potenziell nicht vertrauenswürdige Inhalte verarbeitet werden.

Ein User-Agent SOLLTE zwischen sicheren und unsicheren Methoden unterscheiden, wenn potenzielle Aktionen einem Benutzer präsentiert werden, damit der Benutzer auf eine unsichere Aktion aufmerksam gemacht werden kann, bevor sie angefordert wird.

Wenn eine Ressource so konstruiert ist, dass Parameter innerhalb der effektiven Anfrage-URI den Effekt haben, eine Aktion auszuwählen, liegt es in der Verantwortung des Ressourcenbesitzers sicherzustellen, dass die Aktion mit der Semantik der Anfragemethode übereinstimmt. Beispielsweise ist es bei webbasierter Content-Editing-Software üblich, Aktionen in Abfrageparametern zu verwenden, wie etwa "page?do=delete". Wenn der Zweck einer solchen Ressource darin besteht, eine unsichere Aktion auszuführen, MUSS der Ressourcenbesitzer diese Aktion deaktivieren oder verbieten, wenn sie mit einer sicheren Anfragemethode aufgerufen wird. Andernfalls werden bedauerliche Nebeneffekte auftreten, wenn automatisierte Prozesse auf jede URI-Referenz ein GET zum Zweck der Link-Wartung, des Vorabrufs, der Erstellung eines Suchindex usw. durchführen.

4.2.2. Idempotent Methods (Idempotente Methoden)

Eine Anfragemethode wird als "idempotent" betrachtet, wenn die beabsichtigte Wirkung auf den Server mehrerer identischer Anfragen mit dieser Methode dieselbe ist wie die Wirkung einer einzelnen solchen Anfrage. Von den in dieser Spezifikation definierten Anfragemethoden sind PUT, DELETE und sichere Anfragemethoden idempotent.

Wie die Definition von sicher gilt die idempotente Eigenschaft nur für das, was vom Benutzer angefordert wurde; ein Server kann jede Anfrage separat protokollieren, eine Revisionskontrollhistorie führen oder andere nicht-idempotente Nebeneffekte für jede idempotente Anfrage implementieren.

Idempotente Methoden werden unterschieden, weil die Anfrage automatisch wiederholt werden kann, wenn ein Kommunikationsfehler auftritt, bevor der Client die Antwort des Servers lesen kann. Wenn beispielsweise ein Client eine PUT-Anfrage sendet und die zugrunde liegende Verbindung geschlossen wird, bevor eine Antwort empfangen wird, kann der Client eine neue Verbindung herstellen und die idempotente Anfrage wiederholen. Er weiß, dass die Wiederholung der Anfrage dieselbe beabsichtigte Wirkung hat, auch wenn die ursprüngliche Anfrage erfolgreich war, obwohl die Antwort unterschiedlich sein kann.

4.2.3. Cacheable Methods (Cachefähige Methoden)

Anfragemethoden können als "cachefähig" definiert werden, um anzuzeigen, dass Antworten auf sie für zukünftige Wiederverwendung gespeichert werden dürfen; spezifische Anforderungen siehe [RFC7234]. Im Allgemeinen sind sichere Methoden, die nicht von einer aktuellen oder autoritativen Antwort abhängen, als cachefähig definiert; diese Spezifikation definiert GET, HEAD und POST als cachefähig, obwohl die überwiegende Mehrheit der Cache-Implementierungen nur GET und HEAD unterstützt.

4.3. Method Definitions (Methodendefinitionen)

4.3.1. GET

Die GET-Methode fordert die Übertragung einer aktuell ausgewählten Repräsentation für die Zielressource an. GET ist der primäre Mechanismus zum Abrufen von Informationen und der Fokus fast aller Leistungsoptimierungen. Wenn Menschen also davon sprechen, identifizierbare Informationen über HTTP abzurufen, beziehen sie sich im Allgemeinen darauf, eine GET-Anfrage zu stellen.

Es ist verlockend, Ressourcen-Identifikatoren als Remote-Dateisystempfadnamen und Repräsentationen als Kopie des Inhalts solcher Dateien zu betrachten. Das wäre falsch. Die Repräsentationen, die als Antwort auf GET zurückgegeben werden, sind nicht notwendigerweise nur der Inhalt einer Ressource, wie sie vom Ursprungsserver gespeichert wird. Stattdessen werden sie ausgewählt (über Content-Negotiation) und spontan generiert, abhängig von der Anfrage.

Eine Payload in einer GET-Anfragenachricht hat keine definierte Semantik; das Senden eines Payload-Bodys bei einer GET-Anfrage könnte dazu führen, dass einige bestehende Implementierungen die Anfrage ablehnen.

Die Antwort auf eine GET-Anfrage ist cachefähig; ein Cache KANN sie verwenden, um nachfolgende GET- und HEAD-Anfragen zu erfüllen, sofern nicht anders durch das Cache-Control-Header-Feld angegeben (Section 5.2 von [RFC7234]).

4.3.2. HEAD

Die HEAD-Methode ist identisch mit GET, außer dass der Server NICHT einen Nachrichtentext in der Antwort senden DARF (d.h., die Antwort endet am Ende des Header-Abschnitts). Der Server SOLLTE dieselben Header-Felder als Antwort auf eine HEAD-Anfrage senden, die er gesendet hätte, wenn die Anfrage ein GET gewesen wäre, außer dass die Payload-Header-Felder (Section 3.3) weggelassen werden KÖNNEN. Diese Methode kann verwendet werden, um Metadaten über die ausgewählte Repräsentation zu erhalten, ohne die Repräsentationsdaten zu übertragen, und wird häufig zum Testen von Hypertext-Links auf Gültigkeit, Zugänglichkeit und kürzliche Änderungen verwendet.

Eine Payload in einer HEAD-Anfragenachricht hat keine definierte Semantik; das Senden eines Payload-Bodys bei einer HEAD-Anfrage könnte dazu führen, dass einige bestehende Implementierungen die Anfrage ablehnen.

Die Antwort auf eine HEAD-Anfrage ist cachefähig; ein Cache KANN sie verwenden, um nachfolgende HEAD-Anfragen zu erfüllen, sofern nicht anders durch das Cache-Control-Header-Feld angegeben (Section 5.2 von [RFC7234]). Eine HEAD-Antwort könnte auch Auswirkungen auf zuvor zwischengespeicherte Antworten auf GET haben; siehe Section 4.3.5 von [RFC7234].

4.3.3. POST

Die POST-Methode fordert, dass die Zielressource die in der Anfrage enthaltene Repräsentation gemäß der eigenen spezifischen Semantik der Ressource verarbeitet. POST wird beispielsweise für die folgenden Funktionen verwendet (unter anderem):

• Bereitstellung eines Datenblocks, wie z.B. die in ein HTML-Formular eingegebenen Felder, für einen Datenverarbeitungsprozess;

• Veröffentlichung einer Nachricht auf einem Bulletin Board, einer Newsgroup, einer Mailingliste, einem Blog oder einer ähnlichen Gruppe von Artikeln;

• Erstellung einer neuen Ressource, die noch nicht vom Ursprungsserver identifiziert wurde; und,

• Anhängen von Daten an die bestehenden Repräsentationen einer Ressource.

Ein Ursprungsserver gibt die Antwort-Semantik an, indem er einen geeigneten Statuscode basierend auf dem Ergebnis der Verarbeitung der POST-Anfrage wählt; fast alle in dieser Spezifikation definierten Statuscodes können als Antwort auf POST empfangen werden (die Ausnahmen sind 206 (Partial Content), 304 (Not Modified) und 416 (Range Not Satisfiable)).

Wenn eine oder mehrere Ressourcen auf dem Ursprungsserver als Ergebnis der erfolgreichen Verarbeitung einer POST-Anfrage erstellt wurden, SOLLTE der Ursprungsserver eine 201 (Created) Antwort senden, die ein Location-Header-Feld enthält, das einen Identifikator für die primär erstellte Ressource bereitstellt (Section 7.1.2), und eine Repräsentation, die den Status der Anfrage beschreibt, während auf die neue(n) Ressource(n) verwiesen wird.

Antworten auf POST-Anfragen sind nur cachefähig, wenn sie explizite Frischeinformationen enthalten (siehe Section 4.2.1 von [RFC7234]). POST-Caching ist jedoch nicht weit verbreitet implementiert. Für Fälle, in denen ein Ursprungsserver möchte, dass der Client das Ergebnis eines POST so cachen kann, dass es durch ein späteres GET wiederverwendet werden kann, KANN der Ursprungsserver eine 200 (OK) Antwort senden, die das Ergebnis und ein Content-Location-Header-Feld enthält, das denselben Wert wie die effektive Anfrage-URI des POST hat (Section 3.1.4.2).

Wenn das Ergebnis der Verarbeitung eines POST einer Repräsentation einer vorhandenen Ressource entsprechen würde, KANN ein Ursprungsserver den User-Agent zu dieser Ressource umleiten, indem er eine 303 (See Other) Antwort mit dem Identifikator der vorhandenen Ressource im Location-Feld sendet. Dies hat den Vorteil, dem User-Agent einen Ressourcen-Identifikator bereitzustellen und die Repräsentation über eine Methode zu übertragen, die besser für gemeinsames Caching geeignet ist, allerdings auf Kosten einer zusätzlichen Anfrage, wenn der User-Agent die Repräsentation noch nicht im Cache hat.

4.3.4. PUT

Die PUT-Methode fordert, dass der Zustand der Zielressource mit dem durch die in der Anfragenachricht-Payload enthaltene Repräsentation definierten Zustand erstellt oder ersetzt wird. Ein erfolgreiches PUT einer gegebenen Repräsentation würde darauf hindeuten, dass ein nachfolgendes GET auf derselben Zielressource dazu führen würde, dass eine äquivalente Repräsentation in einer 200 (OK) Antwort gesendet wird. Es gibt jedoch keine Garantie, dass eine solche Zustandsänderung beobachtbar sein wird, da die Zielressource möglicherweise parallel von anderen User-Agents bearbeitet wird oder einer dynamischen Verarbeitung durch den Ursprungsserver unterliegen könnte, bevor ein nachfolgendes GET empfangen wird. Eine erfolgreiche Antwort impliziert nur, dass die Absicht des User-Agents zum Zeitpunkt ihrer Verarbeitung durch den Ursprungsserver erreicht wurde.

Wenn die Zielressource keine aktuelle Repräsentation hat und der PUT erfolgreich eine erstellt, MUSS der Ursprungsserver den User-Agent durch Senden einer 201 (Created) Antwort informieren. Wenn die Zielressource eine aktuelle Repräsentation hat und diese Repräsentation gemäß dem Zustand der enthaltenen Repräsentation erfolgreich geändert wird, MUSS der Ursprungsserver entweder eine 200 (OK) oder eine 204 (No Content) Antwort senden, um die erfolgreiche Vervollständigung der Anfrage anzuzeigen.

Ein Ursprungsserver SOLLTE überprüfen, dass die PUT-Repräsentation mit allen Einschränkungen übereinstimmt, die der Server für die Zielressource hat, die nicht durch den PUT geändert werden können oder nicht geändert werden. Dies ist besonders wichtig, wenn der Ursprungsserver interne Konfigurationsinformationen in Bezug auf die URI verwendet, um die Werte für Repräsentations-Metadaten bei GET-Antworten zu setzen. Wenn eine PUT-Repräsentation mit der Zielressource inkonsistent ist, SOLLTE der Ursprungsserver sie entweder konsistent machen, indem er die Repräsentation transformiert oder die Ressourcenkonfiguration ändert, oder mit einer geeigneten Fehlermeldung antworten, die ausreichende Informationen enthält, um zu erklären, warum die Repräsentation ungeeignet ist. Die Statuscodes 409 (Conflict) oder 415 (Unsupported Media Type) werden vorgeschlagen, wobei letzterer spezifisch für Einschränkungen bei Content-Type-Werten ist.

Wenn beispielsweise die Zielressource so konfiguriert ist, dass sie immer einen Content-Type von "text/html" hat, und die PUT-Repräsentation einen Content-Type von "image/jpeg" hat, sollte der Ursprungsserver eines der folgenden tun:

a. die Zielressource neu konfigurieren, um den neuen Medientyp widerzuspiegeln;

b. die PUT-Repräsentation in ein mit der Ressource konsistentes Format transformieren, bevor sie als neuer Ressourcenzustand gespeichert wird; oder,

c. die Anfrage mit einer 415 (Unsupported Media Type) Antwort ablehnen, die angibt, dass die Zielressource auf "text/html" beschränkt ist, möglicherweise einschließlich eines Links zu einer anderen Ressource, die ein geeignetes Ziel für die neue Repräsentation wäre.

HTTP definiert nicht genau, wie eine PUT-Methode den Zustand eines Ursprungsservers beeinflusst, über das hinaus, was durch die Absicht der User-Agent-Anfrage und die Semantik der Ursprungsserver-Antwort ausgedrückt werden kann. Es definiert nicht, was eine Ressource in irgendeinem Sinne dieses Wortes sein könnte, über die über HTTP bereitgestellte Schnittstelle hinaus. Es definiert nicht, wie der Ressourcenzustand "gespeichert" wird, noch wie sich eine solche Speicherung als Ergebnis einer Änderung im Ressourcenzustand ändern könnte, noch wie der Ursprungsserver den Ressourcenzustand in Repräsentationen übersetzt. Allgemein gesprochen sind alle Implementierungsdetails hinter der Ressourcenschnittstelle vom Server absichtlich verborgen.

Ein Ursprungsserver DARF NICHT ein Validator-Header-Feld (Section 7.2), wie ein ETag- oder Last-Modified-Feld, in einer erfolgreichen Antwort auf PUT senden, es sei denn, die Repräsentationsdaten der Anfrage wurden ohne jegliche auf den Body angewendete Transformation gespeichert (d.h., die neuen Repräsentationsdaten der Ressource sind identisch mit den in der PUT-Anfrage empfangenen Repräsentationsdaten) und der Validator-Feldwert spiegelt die neue Repräsentation wider. Diese Anforderung ermöglicht es einem User-Agent zu wissen, dass der Repräsentations-Body, den er im Speicher hat, als Ergebnis des PUT aktuell bleibt und daher nicht erneut vom Ursprungsserver abgerufen werden muss, und dass die neuen Validatoren, die in der Antwort empfangen wurden, für zukünftige bedingte Anfragen verwendet werden können, um versehentliche Überschreibungen zu verhindern (Section 5.2).

Der grundlegende Unterschied zwischen den POST- und PUT-Methoden wird durch die unterschiedliche Absicht für die enthaltene Repräsentation hervorgehoben. Die Zielressource in einer POST-Anfrage soll die enthaltene Repräsentation gemäß der eigenen Semantik der Ressource verarbeiten, während die enthaltene Repräsentation in einer PUT-Anfrage als Ersatz für den Zustand der Zielressource definiert ist. Daher ist die Absicht von PUT idempotent und für Vermittler sichtbar, auch wenn die genaue Wirkung nur dem Ursprungsserver bekannt ist.

Die richtige Interpretation einer PUT-Anfrage setzt voraus, dass der User-Agent weiß, welche Zielressource gewünscht ist. Ein Dienst, der nach Erhalt einer zustandsändernden Anfrage eine geeignete URI im Namen des Clients auswählt, SOLLTE mit der POST-Methode anstelle von PUT implementiert werden. Wenn der Ursprungsserver die angeforderte PUT-Zustandsänderung nicht an der Zielressource vornimmt und sie stattdessen auf eine andere Ressource anwenden möchte, z.B. wenn die Ressource zu einer anderen URI verschoben wurde, MUSS der Ursprungsserver eine geeignete 3xx (Redirection) Antwort senden; der User-Agent KANN dann seine eigene Entscheidung treffen, ob die Anfrage umgeleitet werden soll oder nicht.

Eine PUT-Anfrage, die auf die Zielressource angewendet wird, kann Nebeneffekte auf andere Ressourcen haben. Beispielsweise könnte ein Artikel eine URI zur Identifizierung "der aktuellen Version" (eine Ressource) haben, die von den URIs zur Identifizierung jeder bestimmten Version (verschiedene Ressourcen, die zu einem Zeitpunkt denselben Zustand wie die aktuelle Versionsressource teilten) getrennt ist. Eine erfolgreiche PUT-Anfrage auf die URI "der aktuellen Version" könnte daher eine neue Versionsressource erstellen, zusätzlich zur Änderung des Zustands der Zielressource, und könnte auch dazu führen, dass Links zwischen den verwandten Ressourcen hinzugefügt werden.

Ein Ursprungsserver, der PUT auf einer gegebenen Zielressource zulässt, MUSS mit einer 400 (Bad Request) Antwort auf eine PUT-Anfrage antworten, die ein Content-Range-Header-Feld enthält (Section 4.2 von [RFC7233]), da die Payload wahrscheinlich teilweiser Inhalt ist, der fälschlicherweise als vollständige Repräsentation PUT wurde. Teilweise Inhaltsaktualisierungen sind möglich, indem eine separat identifizierte Ressource mit einem Zustand anvisiert wird, der einen Teil der größeren Ressource überlappt, oder durch Verwendung einer anderen Methode, die speziell für teilweise Aktualisierungen definiert wurde (beispielsweise die in [RFC5789] definierte PATCH-Methode).

Antworten auf die PUT-Methode sind nicht cachefähig. Wenn eine erfolgreiche PUT-Anfrage durch einen Cache läuft, der eine oder mehrere gespeicherte Antworten für die effektive Anfrage-URI hat, werden diese gespeicherten Antworten invalidiert (siehe Section 4.4 von [RFC7234]).

4.3.5. DELETE

Die DELETE-Methode fordert, dass der Ursprungsserver die Zuordnung zwischen der Zielressource und ihrer aktuellen Funktionalität entfernt. In der Tat ist diese Methode ähnlich dem rm-Befehl in UNIX: Sie drückt eine Löschoperation auf der URI-Zuordnung des Ursprungsservers aus, anstatt zu erwarten, dass die zuvor zugeordneten Informationen gelöscht werden.

Wenn die Zielressource eine oder mehrere aktuelle Repräsentationen hat, könnten sie vom Ursprungsserver zerstört werden oder auch nicht, und der zugehörige Speicher könnte zurückgewonnen werden oder auch nicht, was vollständig von der Natur der Ressource und ihrer Implementierung durch den Ursprungsserver abhängt (die außerhalb des Geltungsbereichs dieser Spezifikation liegen). Ebenso könnten andere Implementierungsaspekte einer Ressource als Folge eines DELETE deaktiviert oder archiviert werden müssen, wie z.B. Datenbank- oder Gateway-Verbindungen. Im Allgemeinen wird angenommen, dass der Ursprungsserver DELETE nur für Ressourcen zulässt, für die er einen vorgeschriebenen Mechanismus zur Durchführung der Löschung hat.

Relativ wenige Ressourcen erlauben die DELETE-Methode -- ihre primäre Verwendung ist für Remote-Authoring-Umgebungen, in denen der Benutzer eine gewisse Anleitung bezüglich ihrer Wirkung hat. Beispielsweise könnte eine Ressource, die zuvor mit einer PUT-Anfrage erstellt wurde oder nach einer 201 (Created) Antwort auf eine POST-Anfrage über das Location-Header-Feld identifiziert wurde, eine entsprechende DELETE-Anfrage zulassen, um diese Aktionen rückgängig zu machen. Ebenso könnten benutzerdefinierte User-Agent-Implementierungen, die eine Authoring-Funktion implementieren, wie z.B. Revisionskontroll-Clients, die HTTP für Remote-Operationen verwenden, DELETE basierend auf der Annahme verwenden, dass der URI-Raum des Servers so gestaltet wurde, dass er einem Versions-Repository entspricht.

Wenn eine DELETE-Methode erfolgreich angewendet wird, SOLLTE der Ursprungsserver einen Statuscode 202 (Accepted) senden, wenn die Aktion wahrscheinlich erfolgreich sein wird, aber noch nicht durchgeführt wurde, einen Statuscode 204 (No Content), wenn die Aktion durchgeführt wurde und keine weiteren Informationen bereitgestellt werden müssen, oder einen Statuscode 200 (OK), wenn die Aktion durchgeführt wurde und die Antwortnachricht eine Repräsentation enthält, die den Status beschreibt.

Eine Payload in einer DELETE-Anfragenachricht hat keine definierte Semantik; das Senden eines Payload-Bodys bei einer DELETE-Anfrage könnte dazu führen, dass einige bestehende Implementierungen die Anfrage ablehnen.

Antworten auf die DELETE-Methode sind nicht cachefähig. Wenn eine DELETE-Anfrage durch einen Cache läuft, der eine oder mehrere gespeicherte Antworten für die effektive Anfrage-URI hat, werden diese gespeicherten Antworten invalidiert (siehe Section 4.4 von [RFC7234]).

4.3.6. CONNECT

Die CONNECT-Methode fordert, dass der Empfänger einen Tunnel zum Ziel-Ursprungsserver herstellt, der durch das Anfrageziel identifiziert wird, und bei Erfolg sein Verhalten danach auf blindes Weiterleiten von Paketen in beide Richtungen beschränkt, bis der Tunnel geschlossen wird. Tunnel werden üblicherweise verwendet, um eine Ende-zu-Ende-Virtualverbindung durch einen oder mehrere Proxies zu erstellen, die dann mit TLS (Transport Layer Security, [RFC5246]) gesichert werden kann.

CONNECT ist nur für die Verwendung in Anfragen an einen Proxy vorgesehen. Ein Ursprungsserver, der eine CONNECT-Anfrage für sich selbst empfängt, KANN mit einem 2xx (Successful) Statuscode antworten, um anzuzeigen, dass eine Verbindung hergestellt wurde. Die meisten Ursprungsserver implementieren CONNECT jedoch nicht.

Ein Client, der eine CONNECT-Anfrage sendet, MUSS die Autoritätsform des Anfrageziels senden (Section 5.3 von [RFC7230]); d.h., das Anfrageziel besteht nur aus dem Hostnamen und der Portnummer des Tunnelziels, getrennt durch einen Doppelpunkt. Zum Beispiel,

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

Der Empfänger-Proxy kann einen Tunnel entweder durch direktes Verbinden mit dem Anfrageziel oder, wenn er für die Verwendung eines anderen Proxys konfiguriert ist, durch Weiterleiten der CONNECT-Anfrage an den nächsten eingehenden Proxy herstellen. Jede 2xx (Successful) Antwort zeigt an, dass der Sender (und alle eingehenden Proxys) unmittelbar nach der Leerzeile, die den Header-Abschnitt der erfolgreichen Antwort abschließt, in den Tunnelmodus wechseln werden; Daten, die nach dieser Leerzeile empfangen werden, stammen vom durch das Anfrageziel identifizierten Server. Jede Antwort außer einer erfolgreichen Antwort zeigt an, dass der Tunnel noch nicht gebildet wurde und die Verbindung weiterhin von HTTP geregelt wird.

Ein Tunnel wird geschlossen, wenn ein Tunnel-Vermittler erkennt, dass eine der beiden Seiten ihre Verbindung geschlossen hat: Der Vermittler MUSS versuchen, alle ausstehenden Daten, die von der geschlossenen Seite kamen, an die andere Seite zu senden, beide Verbindungen zu schließen und dann alle verbleibenden nicht zugestellten Daten zu verwerfen.

Proxy-Authentifizierung kann verwendet werden, um die Berechtigung zur Erstellung eines Tunnels zu etablieren. Zum Beispiel,

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=

Es bestehen erhebliche Risiken bei der Herstellung eines Tunnels zu beliebigen Servern, insbesondere wenn das Ziel ein bekannter oder reservierter TCP-Port ist, der nicht für Web-Verkehr vorgesehen ist. Beispielsweise würde ein CONNECT zu "example.com:25" darauf hindeuten, dass der Proxy sich mit dem reservierten Port für SMTP-Verkehr verbindet; wenn erlaubt, könnte dies den Proxy dazu verleiten, Spam-E-Mails weiterzuleiten. Proxies, die CONNECT unterstützen, SOLLTEN seine Verwendung auf eine begrenzte Menge bekannter Ports oder eine konfigurierbare Liste sicherer Anfrageziele beschränken.

Ein Server DARF KEINE Transfer-Encoding- oder Content-Length-Header-Felder in einer 2xx (Successful) Antwort auf CONNECT senden. Ein Client MUSS alle Content-Length- oder Transfer-Encoding-Header-Felder ignorieren, die in einer erfolgreichen Antwort auf CONNECT empfangen werden.

Eine Payload in einer CONNECT-Anfragenachricht hat keine definierte Semantik; das Senden eines Payload-Bodys bei einer CONNECT-Anfrage könnte dazu führen, dass einige bestehende Implementierungen die Anfrage ablehnen.

Antworten auf die CONNECT-Methode sind nicht cachefähig.

4.3.7. OPTIONS

Die OPTIONS-Methode fordert Informationen über die für die Zielressource verfügbaren Kommunikationsoptionen an, entweder beim Ursprungsserver oder bei einem dazwischenliegenden Vermittler. Diese Methode ermöglicht es einem Client, die mit einer Ressource verbundenen Optionen und/oder Anforderungen oder die Fähigkeiten eines Servers zu bestimmen, ohne eine Ressourcenaktion zu implizieren.

Eine OPTIONS-Anfrage mit einem Sternchen ("") als Anfrageziel (Section 5.3 von [RFC7230]) gilt für den Server im Allgemeinen und nicht für eine spezifische Ressource. Da die Kommunikationsoptionen eines Servers typischerweise von der Ressource abhängen, ist die ""-Anfrage nur als "Ping"- oder "No-Op"-Typ von Methode nützlich; sie tut nichts anderes, als dem Client zu ermöglichen, die Fähigkeiten des Servers zu testen. Dies kann beispielsweise verwendet werden, um einen Proxy auf HTTP/1.1-Konformität (oder deren Fehlen) zu testen.

Wenn das Anfrageziel kein Sternchen ist, gilt die OPTIONS-Anfrage für die Optionen, die bei der Kommunikation mit der Zielressource verfügbar sind.

Ein Server, der eine erfolgreiche Antwort auf OPTIONS generiert, SOLLTE alle Header-Felder senden, die optionale vom Server implementierte Funktionen anzeigen könnten, die auf die Zielressource anwendbar sind (z.B. Allow), einschließlich potenzieller Erweiterungen, die nicht durch diese Spezifikation definiert sind. Die Antwort-Payload, falls vorhanden, könnte die Kommunikationsoptionen auch in einer maschinenlesbaren oder menschenlesbaren Darstellung beschreiben. Ein Standardformat für eine solche Darstellung ist durch diese Spezifikation nicht definiert, könnte aber durch zukünftige Erweiterungen von HTTP definiert werden. Ein Server MUSS ein Content-Length-Feld mit dem Wert "0" generieren, wenn kein Payload-Body in der Antwort gesendet werden soll.

Ein Client KANN ein Max-Forwards-Header-Feld in einer OPTIONS-Anfrage senden, um einen spezifischen Empfänger in der Anfragekette anzusprechen (siehe Section 5.1.2). Ein Proxy DARF NICHT ein Max-Forwards-Header-Feld beim Weiterleiten einer Anfrage generieren, es sei denn, diese Anfrage wurde mit einem Max-Forwards-Feld empfangen.

Ein Client, der eine OPTIONS-Anfrage mit einem Payload-Body generiert, MUSS ein gültiges Content-Type-Header-Feld senden, das den Repräsentations-Medientyp beschreibt. Obwohl diese Spezifikation keine Verwendung für eine solche Payload definiert, könnten zukünftige Erweiterungen von HTTP den OPTIONS-Body verwenden, um detailliertere Abfragen über die Zielressource durchzuführen.

Antworten auf die OPTIONS-Methode sind nicht cachefähig.

4.3.8. TRACE

Die TRACE-Methode fordert einen entfernten Loopback auf Anwendungsebene der Anfragenachricht an. Der endgültige Empfänger der Anfrage SOLLTE die empfangene Nachricht, mit Ausnahme einiger unten beschriebener Felder, als Nachrichtentext einer 200 (OK) Antwort mit einem Content-Type von "message/http" (Section 8.3.1 von [RFC7230]) an den Client zurückspiegeln. Der endgültige Empfänger ist entweder der Ursprungsserver oder der erste Server, der einen Max-Forwards-Wert von Null (0) in der Anfrage empfängt (Section 5.1.2).

Ein Client DARF NICHT Header-Felder in einer TRACE-Anfrage generieren, die sensible Daten enthalten, die durch die Antwort offengelegt werden könnten. Beispielsweise wäre es töricht für einen User-Agent, gespeicherte Benutzer-Credentials [RFC7235] oder Cookies [RFC6265] in einer TRACE-Anfrage zu senden. Der endgültige Empfänger der Anfrage SOLLTE alle Anfrage-Header-Felder ausschließen, die wahrscheinlich sensible Daten enthalten, wenn dieser Empfänger den Antworttext generiert.

TRACE ermöglicht es dem Client zu sehen, was am anderen Ende der Anfragekette empfangen wird, und diese Daten für Test- oder Diagnoseinformationen zu verwenden. Der Wert des Via-Header-Feldes (Section 5.7.1 von [RFC7230]) ist von besonderem Interesse, da es als Spur der Anfragekette fungiert. Die Verwendung des Max-Forwards-Header-Feldes ermöglicht es dem Client, die Länge der Anfragekette zu begrenzen, was zum Testen einer Kette von Proxies nützlich ist, die Nachrichten in einer Endlosschleife weiterleiten.

Ein Client DARF NICHT einen Nachrichtentext in einer TRACE-Anfrage senden.

Antworten auf die TRACE-Methode sind nicht cachefähig.

---