9. Methoden (Methods)

9.1. Überblick (Overview)

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, sofern diese zusätzliche Semantik nicht mit der Methode in Konflikt steht. Beispielsweise kann ein Client bedingte Anfrage-Header-Felder (Abschnitt 13.1) senden, um die angeforderte Aktion vom aktuellen Zustand der Zielressource abhängig zu machen.

HTTP ist so konzipiert, dass es als Schnittstelle zu verteilten Objektsystemen verwendet werden kann. Die Anfragemethode ruft eine Aktion auf, die auf eine Zielressource angewendet werden soll, ähnlich wie ein Remote-Methodenaufruf an ein identifiziertes Objekt gesendet werden kann.

method = token

Das Methoden-Token unterscheidet Groß- und Kleinschreibung, da es möglicherweise als Gateway zu objektbasierten Systemen mit Methodennamen verwendet wird, die zwischen Groß- und Kleinschreibung unterscheiden. Konventionsgemäß werden standardisierte Methoden in Großbuchstaben des US-ASCII-Zeichensatzes definiert.

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 bei Anwendung auf jede Ressource dieselbe Semantik haben, obwohl jede Ressource selbst bestimmt, ob diese Semantik implementiert oder erlaubt ist.

Diese Spezifikation definiert eine Reihe von standardisierten Methoden, die häufig in HTTP verwendet werden, wie in der folgenden Tabelle dargestellt.

Methodenname	Beschreibung	Abschnitt
GET	Übertragung einer aktuellen Repräsentation der Zielressource.	9.3.1
HEAD	Wie GET, aber ohne Übertragung des Antwortinhalts.	9.3.2
POST	Ressourcenspezifische Verarbeitung des Anfrageinhalts durchführen.	9.3.3
PUT	Alle aktuellen Repräsentationen der Zielressource durch den Anfrageinhalt ersetzen.	9.3.4
DELETE	Alle aktuellen Repräsentationen der Zielressource entfernen.	9.3.5
CONNECT	Einen Tunnel zum Server einrichten, der durch die Zielressource identifiziert wird.	9.3.6
OPTIONS	Die Kommunikationsoptionen für die Zielressource beschreiben.	9.3.7
TRACE	Einen Nachrichten-Loopback-Test entlang des Pfads zur Zielressource durchführen.	9.3.8

Alle Allzweck-Server MÜSSEN (MUST) die Methoden GET und HEAD unterstützen. Alle anderen Methoden sind OPTIONAL.

Die Menge der von einer Zielressource erlaubten Methoden kann in einem Allow-Header-Feld (Abschnitt 10.2.1) aufgelistet werden. Die Menge der erlaubten Methoden kann sich jedoch dynamisch ändern. Ein Ursprungsserver, der eine nicht erkannte oder nicht implementierte Anfragemethode erhält, SOLLTE (SHOULD) mit dem Statuscode 501 (Not Implemented) antworten. Ein Ursprungsserver, der eine erkannte und implementierte Anfragemethode erhält, die jedoch für die Zielressource nicht erlaubt ist, SOLLTE (SHOULD) mit dem Statuscode 405 (Method Not Allowed) antworten.

Zusätzliche Methoden außerhalb des Geltungsbereichs dieser Spezifikation wurden für die Verwendung in HTTP spezifiziert. Alle solche Methoden sollten im „Hypertext Transfer Protocol (HTTP) Method Registry" registriert werden, wie in Abschnitt 16.1 beschrieben.

9.2. Gemeinsame Methodeneigenschaften (Common Method Properties)

9.2.1. Sichere Methoden (Safe Methods)

Anfragemethoden gelten als „sicher", wenn ihre definierte Semantik im Wesentlichen schreibgeschützt ist; das heißt, 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 eine ungewöhnliche Belastung des Ursprungsservers verursacht.

Diese Definition sicherer Methoden verhindert nicht, dass eine Implementierung Verhalten einschließt, das potenziell schädlich ist, das nicht vollständig schreibgeschützt ist oder das beim Aufrufen einer sicheren Methode Nebeneffekte verursacht. Wichtig ist jedoch, dass der Client dieses zusätzliche Verhalten nicht angefordert hat und nicht dafür verantwortlich gemacht werden kann. Beispielsweise hängen die meisten Server Anfrageinformationen nach Abschluss jeder Antwort an Zugriffsprotokolldateien an, unabhängig von der Methode, und dies wird als sicher angesehen, selbst wenn der Protokollspeicher voll werden und den Server zum Ausfall bringen könnte. Ebenso hat eine sichere Anfrage, die durch Auswahl einer Werbung im Web initiiert wird, häufig den Nebeneffekt, einem Werbekonto Kosten zu berechnen.

Von den durch diese 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, automatischen Abrufprozessen (Spiders) und Cache-Leistungsoptimierungen (Vorabladen) zu ermöglichen, ohne Angst vor Schäden zu arbeiten. Darüber hinaus ermöglicht es einem User-Agent, bei der Verarbeitung potenziell nicht vertrauenswürdiger Inhalte angemessene Einschränkungen für die automatische Verwendung unsicherer Methoden anzuwenden.

Ein User-Agent SOLLTE (SHOULD) bei der Präsentation potenzieller Aktionen für einen Benutzer zwischen sicheren und unsicheren Methoden unterscheiden, damit der Benutzer auf eine unsichere Aktion aufmerksam gemacht werden kann, bevor sie angefordert wird.

Wenn eine Ressource so konstruiert ist, dass Parameter innerhalb des Ziel-URI die Wirkung 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 Inhaltsbearbeitungssoftware üblich, Aktionen in Abfrageparametern zu verwenden, wie z. B. „page?do=delete". Wenn der Zweck einer solchen Ressource darin besteht, eine unsichere Aktion auszuführen, MUSS (MUST) der Ressourcenbesitzer diese Aktion deaktivieren oder verbieten, wenn mit einer sicheren Anfragemethode darauf zugegriffen wird. Andernfalls führt dies zu unglücklichen Nebeneffekten, wenn automatisierte Prozesse ein GET für jede URI-Referenz zum Zweck der Linkwartung, des Vorladens, des Aufbaus eines Suchindex usw. durchführen.

9.2.2. Idempotente Methoden (Idempotent Methods)

Eine Anfragemethode gilt als „idempotent", wenn die beabsichtigte Wirkung mehrerer identischer Anfragen mit dieser Methode auf den Server dieselbe ist wie die Wirkung einer einzigen solchen Anfrage. Von den durch diese 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 das Wiederholen der Anfrage denselben beabsichtigten Effekt hat, selbst wenn die ursprüngliche Anfrage erfolgreich war, obwohl die Antwort unterschiedlich sein kann.

Ein Client SOLLTE NICHT (SHOULD NOT) automatisch eine Anfrage mit einer nicht idempotenten Methode wiederholen, es sei denn, er hat ein Mittel zu wissen, dass die Anfrage-Semantik tatsächlich idempotent ist, unabhängig von der Methode, oder ein Mittel zu erkennen, dass die ursprüngliche Anfrage niemals angewendet wurde.

Beispielsweise kann ein User-Agent eine POST-Anfrage automatisch wiederholen, wenn er (durch Design oder Konfiguration) weiß, dass die Anfrage für diese Ressource sicher ist. Ebenso könnte ein User-Agent, der speziell für den Betrieb auf einem Versionskontroll-Repository entwickelt wurde, in der Lage sein, sich von teilweisen Fehlerzuständen zu erholen, indem er nach einer fehlgeschlagenen Verbindung die Zielressource-Revision(en) überprüft, teilweise angewendete Änderungen rückgängig macht oder korrigiert und dann automatisch die fehlgeschlagenen Anfragen wiederholt.

Einige Clients verfolgen einen riskanteren Ansatz und versuchen zu erraten, wann eine automatische Wiederholung möglich ist. Beispielsweise könnte ein Client eine POST-Anfrage automatisch wiederholen, wenn die zugrunde liegende Transportverbindung geschlossen wurde, bevor ein Teil einer Antwort empfangen wurde, insbesondere wenn eine im Leerlauf befindliche persistente Verbindung verwendet wurde.

Ein Proxy DARF NICHT (MUST NOT) automatisch nicht idempotente Anfragen wiederholen. Ein Client SOLLTE NICHT (SHOULD NOT) automatisch eine fehlgeschlagene automatische Wiederholung wiederholen.

9.2.3. Methoden und Caching (Methods and Caching)

Damit ein Cache eine Antwort speichern und verwenden kann, muss die zugehörige Methode das Caching explizit erlauben und detailliert angeben, unter welchen Bedingungen eine Antwort verwendet werden kann, um nachfolgende Anfragen zu erfüllen; eine Methodendefinition, die dies nicht tut, kann nicht zwischengespeichert werden. Für zusätzliche Anforderungen siehe [CACHING].

Diese Spezifikation definiert Caching-Semantik für GET, HEAD und POST, obwohl die überwiegende Mehrheit der Cache-Implementierungen nur GET und HEAD unterstützt.

9.3. Methodendefinitionen (Method Definitions)

9.3.1. GET

Die GET-Methode fordert die Übertragung einer aktuell ausgewählten Repräsentation für die Zielressource an. Eine erfolgreiche Antwort spiegelt die Qualität der „Gleichheit" wider, die durch den Ziel-URI identifiziert wird (Abschnitt 1.2.2 von [URI]). Daher wird das Abrufen identifizierbarer Informationen über HTTP normalerweise durchgeführt, indem eine GET-Anfrage an einen Bezeichner gestellt wird, der mit dem Potenzial verbunden ist, diese Informationen in einer 200 (OK) Antwort bereitzustellen.

GET ist der primäre Mechanismus zum Abrufen von Informationen und der Fokus fast aller Leistungsoptimierungen. Anwendungen, die für jede wichtige Ressource einen URI generieren, können von diesen Optimierungen profitieren und gleichzeitig deren Wiederverwendung durch andere Anwendungen ermöglichen, wodurch ein Netzwerkeffekt entsteht, der die weitere Expansion des Webs fördert.

Es ist verlockend, Ressourcenbezeichner als Remote-Dateisystem-Pfadnamen zu betrachten und Repräsentationen als Kopie des Inhalts solcher Dateien zu betrachten. Tatsächlich werden viele Ressourcen auf diese Weise implementiert (siehe Abschnitt 17.3 für verwandte Sicherheitsüberlegungen). In der Praxis gibt es jedoch keine solchen Einschränkungen.

Die HTTP-Schnittstelle für eine Ressource kann ebenso wahrscheinlich als Baum von Inhaltsobjekten, als programmatische Ansicht verschiedener Datenbankdatensätze oder als Gateway zu anderen Informationssystemen implementiert werden. Selbst wenn der URI-Zuordnungsmechanismus an ein Dateisystem gebunden ist, kann ein Ursprungsserver so konfiguriert sein, dass er die Datei mit der Anfrage als Eingabe ausführt und die Ausgabe als Repräsentation sendet, anstatt die Datei direkt zu übertragen. Wie auch immer, nur der Ursprungsserver muss wissen, wie jeder seiner Ressourcenbezeichner einer Implementierung entspricht und wie diese Implementierung es schafft, eine aktuelle Repräsentation der Zielressource auszuwählen und zu senden.

Ein Client kann die Semantik von GET zu einer „Range-Anfrage" ändern und nur die Übertragung einiger Teile der ausgewählten Repräsentation anfordern, indem er ein Range-Header-Feld in der Anfrage sendet (Abschnitt 14.2).

Obwohl die Rahmung der Anfragenachricht unabhängig von der verwendeten Methode ist, hat in einer GET-Anfrage empfangener Inhalt keine allgemein definierte Semantik, kann die Bedeutung oder das Ziel der Anfrage nicht ändern und kann dazu führen, dass einige Implementierungen die Anfrage ablehnen und die Verbindung schließen, da sie als Anfrage-Smuggling-Angriff (Abschnitt 11.2 von [HTTP/1.1]) dienen könnte. Ein Client SOLLTE NICHT (SHOULD NOT) Inhalt in einer GET-Anfrage generieren, es sei denn, sie wird direkt an einen Ursprungsserver gestellt, der zuvor (in-band oder out-of-band) angezeigt hat, dass eine solche Anfrage einen Zweck hat und angemessen unterstützt wird. Ein Ursprungsserver SOLLTE NICHT (SHOULD NOT) sich auf private Vereinbarungen zum Empfang von Inhalten verlassen, da Teilnehmer an der HTTP-Kommunikation oft nicht über Vermittler in der Anfragekette Bescheid wissen.

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

Wenn das Abrufen von Informationen mit einem Mechanismus durchgeführt wird, der einen Ziel-URI aus vom Benutzer bereitgestellten Informationen konstruiert, wie z. B. die Abfragefelder eines Formulars mit GET, könnten potenziell sensible Daten bereitgestellt werden, die nicht für die Offenlegung innerhalb eines URI geeignet wären (siehe Abschnitt 17.9). In einigen Fällen können die Daten so gefiltert oder transformiert werden, dass sie solche Informationen nicht preisgeben. In anderen Fällen, insbesondere wenn es keinen Nutzen aus dem Caching einer Antwort gibt, kann die Verwendung der POST-Methode (Abschnitt 9.3.3) anstelle von GET solche Informationen im Anfrageinhalt anstatt im Ziel-URI übertragen.

9.3.2. HEAD

Die HEAD-Methode ist mit GET identisch, außer dass der Server KEINEN (MUST NOT) Inhalt in der Antwort senden darf. HEAD wird verwendet, um Metadaten über die ausgewählte Repräsentation zu erhalten, ohne deren Repräsentationsdaten zu übertragen, oft zum Testen von Hypertext-Links oder zum Finden kürzlicher Änderungen.

Der Server SOLLTE (SHOULD) in der Antwort auf eine HEAD-Anfrage dieselben Header-Felder senden, die er in der Antwort auf eine GET-Anfrage gesendet hätte. Ein Server KANN (MAY) jedoch Header-Felder weglassen, für die ein Wert nur beim Generieren des Inhalts bestimmt wird. Beispielsweise puffern einige Server eine dynamische Antwort auf GET, bis eine Mindestmenge an Daten generiert wurde, damit sie kleine Antworten effizienter abgrenzen oder späte Entscheidungen bezüglich der Inhaltsauswahl treffen können. Eine solche Antwort auf GET könnte beispielsweise Content-Length- und Vary-Felder enthalten, die nicht in einer HEAD-Antwort generiert werden. Diese kleinen Inkonsistenzen werden als vorzuziehen gegenüber dem Generieren und Verwerfen des Inhalts für eine HEAD-Anfrage angesehen, da HEAD normalerweise aus Effizienzgründen angefordert wird.

Obwohl die Rahmung der Anfragenachricht unabhängig von der verwendeten Methode ist, hat in einer HEAD-Anfrage empfangener Inhalt keine allgemein definierte Semantik, kann die Bedeutung oder das Ziel der Anfrage nicht ändern und kann dazu führen, dass einige Implementierungen die Anfrage ablehnen und die Verbindung schließen, da sie als Anfrage-Smuggling-Angriff (Abschnitt 11.2 von [HTTP/1.1]) dienen könnte. Ein Client SOLLTE NICHT (SHOULD NOT) Inhalt in einer HEAD-Anfrage generieren, es sei denn, sie wird direkt an einen Ursprungsserver gestellt, der zuvor (in-band oder out-of-band) angezeigt hat, dass eine solche Anfrage einen Zweck hat und angemessen unterstützt wird. Ein Ursprungsserver SOLLTE NICHT (SHOULD NOT) sich auf private Vereinbarungen zum Empfang von Inhalten verlassen, da Teilnehmer an der HTTP-Kommunikation oft nicht über Vermittler in der Anfragekette Bescheid wissen.

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

9.3.3. POST

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

• Bereitstellung eines Datenblocks, wie z. B. in ein HTML-Formular eingegebene Felder, an einen Datenverarbeitungsprozess;
• Veröffentlichung einer Nachricht auf einem schwarzen Brett, einer Newsgroup, einer Mailingliste, einem Blog oder einer ähnlichen Artikelgruppe;
• Erstellung einer neuen Ressource, die noch nicht vom Ursprungsserver identifiziert wurde; und
• Anhängen von Daten an die vorhandenen Repräsentationen einer Ressource.

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

Wenn auf dem Ursprungsserver als Ergebnis der erfolgreichen Verarbeitung einer POST-Anfrage eine oder mehrere Ressourcen erstellt wurden, SOLLTE (SHOULD) der Ursprungsserver eine 201 (Created) Antwort senden, die ein Location-Header-Feld (Abschnitt 10.2.2) enthält, das einen Bezeichner für die erstellte primäre Ressource bereitstellt, 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 Frische-Informationen enthalten (siehe Abschnitt 4.2.1 von [CACHING]) und ein Content-Location-Header-Feld (Abschnitt 8.7), das denselben Wert wie der Ziel-URI des POST hat. Eine zwischengespeicherte POST-Antwort kann wiederverwendet werden, um eine spätere GET- oder HEAD-Anfrage zu erfüllen. Im Gegensatz dazu kann eine POST-Anfrage nicht durch eine zwischengespeicherte POST-Antwort erfüllt werden, da POST potenziell unsicher ist; siehe Abschnitt 4 von [CACHING].

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

9.3.4. PUT

Die PUT-Methode fordert an, dass der Zustand der Zielressource mit dem durch die im Nachrichteninhalt der Anfrage 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 dieselbe 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 ist, da die Zielressource möglicherweise parallel von anderen User-Agents bearbeitet wird oder einer dynamischen Verarbeitung durch den Ursprungsserver unterliegt, 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 das PUT erfolgreich eine erstellt, MUSS (MUST) der Ursprungsserver den User-Agent informieren, indem er eine 201 (Created) Antwort sendet. Wenn die Zielressource eine aktuelle Repräsentation hat und diese Repräsentation gemäß dem Zustand der enthaltenen Repräsentation erfolgreich geändert wurde, MUSS (MUST) der Ursprungsserver entweder eine 200 (OK) oder eine 204 (No Content) Antwort senden, um den erfolgreichen Abschluss der Anfrage anzuzeigen.

Ein Ursprungsserver SOLLTE (SHOULD) überprüfen, dass die PUT-Repräsentation mit seinen konfigurierten Einschränkungen für die Zielressource übereinstimmt. Wenn beispielsweise ein Ursprungsserver die Repräsentationsmetadaten einer Ressource basierend auf dem URI bestimmt, muss der Ursprungsserver sicherstellen, dass der in einer erfolgreichen PUT-Anfrage empfangene Inhalt mit diesen Metadaten übereinstimmt. Wenn eine PUT-Repräsentation nicht mit der Zielressource übereinstimmt, SOLLTE (SHOULD) der Ursprungsserver sie entweder durch Transformation der Repräsentation oder durch Änderung der Ressourcenkonfiguration konsistent machen oder mit einer geeigneten Fehlermeldung antworten, die ausreichend 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 Repräsentation, die PUT wird, einen Content-Type von „image/jpeg" hat, sollte der Ursprungsserver eines der folgenden Dinge tun:

a. die Zielressource neu konfigurieren, um den neuen Medientyp widerzuspiegeln; b. die PUT-Repräsentation in ein mit der Ressource konsistentes Format umwandeln, 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 irgendeiner Bedeutung 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 des Ressourcenzustands ändern könnte, noch wie der Ursprungsserver den Ressourcenzustand in Repräsentationen übersetzt. Allgemein gesprochen sind alle Implementierungsdetails hinter der Ressourcenschnittstelle absichtlich vom Server verborgen.

Dies erstreckt sich darauf, wie der Ursprungsserver entscheidet, einen Bezeichner mit einer Ressource zu verknüpfen. Der Ursprungsserver ist allein verantwortlich für die Zuordnung eines Ziel-URI zu einer Ressource und somit allein verantwortlich für die Erstellung, Änderung oder Zerstörung dieser Ressource. Es gibt keine erforderliche Beziehung zwischen der Form eines Ziel-URI und einem vom Ursprungsserver verwalteten internen Zustand, wodurch URIs für jeden Client undurchsichtig sind, der nicht über Serverimplementierungsdetails informiert ist.

Ein Ursprungsserver DARF NICHT (MUST NOT) ein Validator-Feld (Abschnitt 8.8), 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 Inhalt angewendete Transformation gespeichert (d. h. die neuen Repräsentationsdaten der Ressource sind identisch mit dem in der PUT-Anfrage empfangenen Inhalt) und der Wert des Validator-Felds die neue Repräsentation widerspiegelt. Diese Anforderung ermöglicht es einem User-Agent zu wissen, wann die von ihm gesendete (und im Speicher behaltene) Repräsentation das Ergebnis des PUT ist, und er sie daher nicht erneut vom Ursprungsserver abrufen muss. Der/die neue(n) in der Antwort empfangene(n) Validator(en) kann/können für zukünftige bedingte Anfragen verwendet werden, um versehentliche Überschreibungen zu verhindern (Abschnitt 13.1).

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 in einer PUT-Anfrage enthaltene Repräsentation definiert ist, den Zustand der Zielressource zu ersetzen. Daher ist die Absicht von PUT idempotent und für Vermittler sichtbar, auch wenn die genaue Wirkung nur vom Ursprungsserver bekannt ist.

Die korrekte Interpretation einer PUT-Anfrage setzt voraus, dass der User-Agent weiß, welche Zielressource gewünscht wird. Ein Dienst, der im Namen des Clients einen geeigneten URI auswählt, nachdem er eine zustandsändernde Anfrage erhalten hat, SOLLTE (SHOULD) mit der POST-Methode anstelle von PUT implementiert werden. Wenn der Ursprungsserver die angeforderte PUT-Zustandsänderung nicht an der Zielressource vornimmt und stattdessen möchte, dass sie auf eine andere Ressource angewendet wird, wie z. B. wenn die Ressource zu einem anderen URI verschoben wurde, MUSS (MUST) der Ursprungsserver eine geeignete 3xx (Redirection) Antwort senden; der User-Agent KANN (MAY) 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 einen URI haben, um „die aktuelle Version" (eine Ressource) zu identifizieren, die von den URIs getrennt ist, die jede bestimmte Version identifizieren (verschiedene Ressourcen, die zu einem bestimmten Zeitpunkt denselben Zustand wie die aktuelle Versionsressource teilten). Ein erfolgreiches PUT auf den „aktuelle Version"-URI 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 zugehörigen Ressourcen hinzugefügt werden.

Ein Ursprungsserver, der PUT auf einer gegebenen Zielressource erlaubt, MUSS (MUST) eine 400 (Bad Request) Antwort auf eine PUT-Anfrage senden, die ein Content-Range-Header-Feld (Abschnitt 14.4) enthält, da der Inhalt möglicherweise nicht vollständig ist. Teilweise Inhaltsaktualisierungen sind möglich, indem man eine separat identifizierte Ressource mit einem Zustand anvisiert, der einen Teil der größeren Ressource überlappt, oder indem man eine andere Methode verwendet, die speziell für teilweise Aktualisierungen definiert wurde (z. B. die in [RFC5789] definierte PATCH-Methode).

Antworten auf PUT-Anfragen sind nicht cachefähig. Wenn eine erfolgreiche PUT-Anfrage einen Cache passiert, der eine oder mehrere gespeicherte Antworten für den Ziel-URI hat, werden diese gespeicherten Antworten ungültig gemacht (siehe Abschnitt 4.4 von [CACHING]).

9.3.5. DELETE

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

Wenn die Zielressource eine oder mehrere aktuelle Repräsentationen hat, können sie vom Ursprungsserver zerstört werden oder nicht, und der zugeordnete Speicher kann zurückgewonnen werden oder nicht, was vollständig von der Natur der Ressource und ihrer Implementierung durch den Ursprungsserver abhängt (was außerhalb des Geltungsbereichs dieser Spezifikation liegt). Ebenso müssen möglicherweise andere Implementierungsaspekte einer Ressource als Ergebnis eines DELETE deaktiviert oder archiviert werden, wie z. B. Datenbank- oder Gateway-Verbindungen. Im Allgemeinen wird angenommen, dass der Ursprungsserver DELETE nur für Ressourcen erlaubt, 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 Richtung bezüglich ihrer Wirkung hat. Beispielsweise könnte eine Ressource, die zuvor mit einer PUT-Anfrage erstellt wurde oder über das Location-Header-Feld nach einer 201 (Created) Antwort auf eine POST-Anfrage identifiziert wurde, eine entsprechende DELETE-Anfrage erlauben, 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 wurde, SOLLTE (SHOULD) der Ursprungsserver senden:

• einen 202 (Accepted) Statuscode, wenn die Aktion wahrscheinlich erfolgreich sein wird, aber noch nicht durchgeführt wurde,
• einen 204 (No Content) Statuscode, wenn die Aktion durchgeführt wurde und keine weiteren Informationen bereitgestellt werden sollen, oder
• einen 200 (OK) Statuscode, wenn die Aktion durchgeführt wurde und die Antwortnachricht eine Repräsentation enthält, die den Status beschreibt.

Obwohl die Rahmung der Anfragenachricht unabhängig von der verwendeten Methode ist, hat in einer DELETE-Anfrage empfangener Inhalt keine allgemein definierte Semantik, kann die Bedeutung oder das Ziel der Anfrage nicht ändern und kann dazu führen, dass einige Implementierungen die Anfrage ablehnen und die Verbindung schließen, da sie als Anfrage-Smuggling-Angriff (Abschnitt 11.2 von [HTTP/1.1]) dienen könnte. Ein Client SOLLTE NICHT (SHOULD NOT) Inhalt in einer DELETE-Anfrage generieren, es sei denn, sie wird direkt an einen Ursprungsserver gestellt, der zuvor (in-band oder out-of-band) angezeigt hat, dass eine solche Anfrage einen Zweck hat und angemessen unterstützt wird. Ein Ursprungsserver SOLLTE NICHT (SHOULD NOT) sich auf private Vereinbarungen zum Empfang von Inhalten verlassen, da Teilnehmer an der HTTP-Kommunikation oft nicht über Vermittler in der Anfragekette Bescheid wissen.

Antworten auf DELETE-Anfragen sind nicht cachefähig. Wenn eine erfolgreiche DELETE-Anfrage einen Cache passiert, der eine oder mehrere gespeicherte Antworten für den Ziel-URI hat, werden diese gespeicherten Antworten ungültig gemacht (siehe Abschnitt 4.4 von [CACHING]).

9.3.6. CONNECT

Die CONNECT-Methode fordert den Empfänger auf, einen Tunnel zum Ziel-Ursprungsserver einzurichten, der durch das request-target identifiziert wird, und im Erfolgsfall sein Verhalten danach auf blindes Weiterleiten von Daten in beide Richtungen zu beschränken, bis der Tunnel geschlossen wird. Tunnel werden üblicherweise verwendet, um eine End-to-End-Virtualverbindung durch einen oder mehrere Proxys zu erstellen, die dann mit TLS (Transport Layer Security, [TLS13]) gesichert werden kann.

CONNECT ist nur für die Verwendung in Anfragen an einen Proxy vorgesehen. Ein Client, der eine CONNECT-Anfrage sendet, MUSS (MUST) die Autoritätsform des request-target senden (Abschnitt 7.1); das heißt, das request-target 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

Der Empfänger-Proxy kann einen Tunnel entweder durch direkte Verbindung mit dem durch das request-target identifizierten Server einrichten oder, wenn er für die Verwendung eines anderen Proxys konfiguriert ist, indem er die CONNECT-Anfrage an den nächsten eingehenden Proxy weiterleitet. Jede 2xx (Successful) Antwort zeigt an, dass der Sender (und alle eingehenden Proxys) unmittelbar nach dem Antwort-Header-Abschnitt in den Tunnelmodus wechseln; die nach dieser Antwort empfangenen Daten stammen vom durch das request-target identifizierten Server. Jede andere Antwort als eine erfolgreiche Antwort zeigt an, dass der Tunnel noch nicht gebildet wurde.

Ein Tunnel wird geschlossen, wenn ein Tunnel-Vermittler erkennt, dass eine Seite ihre Verbindung geschlossen hat: Der Vermittler MUSS (MUST) 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.

Ein Ursprungsserver KANN (MAY) eine CONNECT-Anfrage akzeptieren und als ein Ende des Tunnels teilnehmen, wenn er sich dafür entscheidet, vermutlich aus guten Gründen im Zusammenhang mit Netzwerksicherheit oder Firewall-Richtlinien. In diesem Fall kann der Ursprungsserver die Verbindung beenden (wenn sie direkt vom Client empfangen wurde), die gesamte Anfragenachricht als die blind weiterzuleitenden Daten behandeln und diese Daten an den identifizierten Listening-Dienst weiterleiten. Alternativ kann der Ursprungsserver die Anfragenachricht so behandeln, als ob sie auf seine eigene Konfiguration angewendet werden sollte, was Firewall-Beschränkungen für ausgehenden Verkehr umgehen würde (unter der Annahme, dass sowohl Quell- als auch Ziel-Client/Server-Paare vom selben Systemadministrator kontrolliert werden). In jedem Fall KANN (MAY) der Ursprungsserver Zugriffskontrollen basierend auf der Anfragenachricht für ein solches CONNECT anwenden, da es Auswirkungen auf Sicherheit oder Betrieb haben könnte, wenn es blind weitergeleitet wird.

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

Eine CONNECT-Anfragenachricht hat keinen Inhalt. Die Interpretation der nach einer CONNECT-Anfrage gesendeten Daten ist spezifisch für die verwendete HTTP-Version. Siehe Abschnitt 9.3.6 von [HTTP/1.1] für Details zu CONNECT in HTTP/1.1.

Antworten auf CONNECT-Anfragen sind nicht cachefähig.

9.3.7. OPTIONS

Die OPTIONS-Methode fordert Informationen über die Kommunikationsoptionen an, die für die Zielressource verfügbar sind, entweder auf dem 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 request-target (Abschnitt 7.1) gilt für den Server im Allgemeinen und nicht für eine bestimmte Ressource. Da die Kommunikationsoptionen eines Servers typischerweise von der Ressource abhängen, ist die „"-Anfrage nur als „Ping"- oder „No-Op"-Typ-Methode nützlich; sie tut nichts weiter, 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 request-target 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 (SHOULD) alle Header-Felder senden, die optionale vom Server implementierte und auf die Zielressource anwendbare Funktionen anzeigen könnten (z. B. Allow), einschließlich potenzieller Erweiterungen, die nicht von dieser Spezifikation definiert sind. Der Antwortinhalt, falls vorhanden, könnte auch die Kommunikationsoptionen in einer maschinen- oder menschenlesbaren Repräsentation beschreiben. Ein Standardformat für eine solche Repräsentation ist nicht von dieser Spezifikation definiert, könnte aber durch zukünftige Erweiterungen zu HTTP definiert werden.

Ein Client KANN (MAY) ein Max-Forwards-Header-Feld in einer OPTIONS-Anfrage senden, um einen bestimmten Empfänger in der Anfragekette anzusprechen (siehe Abschnitt 7.6.2). Ein Proxy DARF NICHT (MUST NOT) 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 Inhalt generiert, MUSS (MUST) ein gültiges Content-Type-Header-Feld senden, das den Repräsentationsmedientyp beschreibt. Obwohl diese Spezifikation keine Verwendung für einen solchen Inhalt definiert, könnten zukünftige Erweiterungen zu HTTP den OPTIONS-Inhalt verwenden, um detailliertere Abfragen über die Zielressource zu stellen.

Antworten auf OPTIONS-Anfragen sind nicht cachefähig.

9.3.8. TRACE

Die TRACE-Methode fordert einen Remote-Loopback auf Anwendungsebene der Anfragenachricht an. Der endgültige Empfänger der Anfrage SOLLTE (SHOULD) die empfangene Nachricht, mit Ausnahme einiger unten beschriebener Felder, an den Client als Inhalt einer 200 (OK) Antwort zurückgeben, deren Content-Type „message/http" ist (Abschnitt 8.3.1 von [HTTP/1.1]). Der endgültige Empfänger ist entweder der Ursprungsserver oder der erste Server, der einen Max-Forwards-Wert von Null (0) in der Anfrage erhält (Abschnitt 7.6.2).

Ein Client DARF NICHT (MUST NOT) 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 Benutzeranmeldeinformationen [HTTP-AUTH] oder Cookies [COOKIE] in einer TRACE-Anfrage zu senden. Der endgültige Empfänger der Anfrage SOLLTE (SHOULD) alle Anfrage-Header-Felder ausschließen, die wahrscheinlich sensible Daten enthalten, wenn dieser Empfänger den Antwortinhalt 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-Felds (Abschnitt 7.6.3) ist von besonderem Interesse, da es als Trace der Anfragekette fungiert. Die Verwendung des Max-Forwards-Header-Felds ermöglicht es dem Client, die Länge der Anfragekette zu begrenzen, was zum Testen einer Kette von Proxys nützlich ist, die Nachrichten in einer Endlosschleife weiterleiten.

Ein Client DARF NICHT (MUST NOT) Inhalt in einer TRACE-Anfrage senden.

Antworten auf TRACE-Anfragen sind nicht cachefähig.