6. Response Status Codes (Antwort-Statuscodes)

Das status-code-Element ist ein dreistelliger Ganzzahlcode, der das Ergebnis des Versuchs angibt, die Anfrage zu verstehen und zu erfüllen.

HTTP-Statuscodes sind erweiterbar. HTTP-Clients müssen die Bedeutung aller registrierten Statuscodes nicht verstehen, obwohl ein solches Verständnis offensichtlich wünschenswert ist. Ein Client MUSS jedoch die Klasse eines beliebigen Statuscodes verstehen, wie durch die erste Ziffer angegeben, und einen nicht erkannten Statuscode als gleichwertig mit dem x00-Statuscode dieser Klasse behandeln, mit der Ausnahme, dass ein Empfänger eine Antwort mit einem nicht erkannten Statuscode NICHT cachen DARF.

Wenn ein Client beispielsweise einen nicht erkannten Statuscode von 471 erhält, kann der Client davon ausgehen, dass mit seiner Anfrage etwas nicht stimmt, und die Antwort so behandeln, als hätte er einen 400 (Bad Request)-Statuscode erhalten. Die Antwortnachricht enthält normalerweise eine Darstellung, die den Status erklärt.

Die erste Ziffer des Statuscodes definiert die Klasse der Antwort. Die letzten beiden Ziffern haben keine Kategorisierungsrolle. Es gibt fünf Werte für die erste Ziffer:

• 1xx (Informational / Informativ): Die Anfrage wurde empfangen, Verarbeitung läuft
• 2xx (Successful / Erfolgreich): Die Anfrage wurde erfolgreich empfangen, verstanden und akzeptiert
• 3xx (Redirection / Umleitung): Weitere Maßnahmen müssen ergriffen werden, um die Anfrage zu vervollständigen
• 4xx (Client Error / Client-Fehler): Die Anfrage enthält fehlerhafte Syntax oder kann nicht erfüllt werden
• 5xx (Server Error / Server-Fehler): Der Server konnte eine scheinbar gültige Anfrage nicht erfüllen

6.1. Overview of Status Codes (Übersicht der Statuscodes)

Die unten aufgeführten Statuscodes sind in dieser Spezifikation definiert. Die hier aufgeführten Reason Phrases sind nur Empfehlungen -- sie können durch lokale Äquivalente ersetzt werden, ohne das Protokoll zu beeinflussen.

Antworten mit Statuscodes, die standardmäßig als cachefähig definiert sind (z. B. 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 und 501 in dieser Spezifikation), können von einem Cache mit heuristischer Ablaufzeit wiederverwendet werden, sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben [RFC7234]; alle anderen Statuscodes sind standardmäßig nicht cachefähig.

Code	Reason Phrase	Definiert in
100	Continue	Section 6.2.1
101	Switching Protocols	Section 6.2.2
200	OK	Section 6.3.1
201	Created	Section 6.3.2
202	Accepted	Section 6.3.3
203	Non-Authoritative Information	Section 6.3.4
204	No Content	Section 6.3.5
205	Reset Content	Section 6.3.6
206	Partial Content	RFC7233
300	Multiple Choices	Section 6.4.1
301	Moved Permanently	Section 6.4.2
302	Found	Section 6.4.3
303	See Other	Section 6.4.4
304	Not Modified	RFC7232
305	Use Proxy	Section 6.4.5
306	(Unused)	Section 6.4.6
307	Temporary Redirect	Section 6.4.7
400	Bad Request	Section 6.5.1
401	Unauthorized	RFC7235
402	Payment Required	Section 6.5.2
403	Forbidden	Section 6.5.3
404	Not Found	Section 6.5.4
405	Method Not Allowed	Section 6.5.5
406	Not Acceptable	Section 6.5.6
407	Proxy Authentication Required	RFC7235
408	Request Timeout	Section 6.5.7
409	Conflict	Section 6.5.8
410	Gone	Section 6.5.9
411	Length Required	Section 6.5.10
412	Precondition Failed	RFC7232
413	Payload Too Large	Section 6.5.11
414	URI Too Long	Section 6.5.12
415	Unsupported Media Type	Section 6.5.13
416	Range Not Satisfiable	RFC7233
417	Expectation Failed	Section 6.5.14
426	Upgrade Required	Section 6.5.15
500	Internal Server Error	Section 6.6.1
501	Not Implemented	Section 6.6.2
502	Bad Gateway	Section 6.6.3
503	Service Unavailable	Section 6.6.4
504	Gateway Timeout	Section 6.6.5
505	HTTP Version Not Supported	Section 6.6.6

6.2. Informational 1xx (Informativ 1xx)

Die 1xx (Informational)-Klasse von Statuscodes zeigt eine vorläufige Antwort zur Kommunikation des Verbindungsstatus oder Anfrage-Fortschritts an, bevor die angeforderte Aktion abgeschlossen und eine endgültige Antwort gesendet wird. Da HTTP/1.0 keine 1xx-Statuscodes definiert hat, DARF ein Server KEINE 1xx-Antwort an einen HTTP/1.0-Client senden.

Eine 1xx-Antwort wird durch die erste Leerzeile nach der Statuszeile beendet (die Leerzeile signalisiert das Ende des Header-Abschnitts). Da eine 1xx-Antwort keinen Nachrichtenkörper enthalten kann, wird sie immer durch die erste Leerzeile nach den Header-Feldern beendet.

HTTP/1.1-Clients MÜSSEN darauf vorbereitet sein, eine oder mehrere 1xx-Antworten vor einer endgültigen Antwort zu empfangen, auch wenn der Client keine 100 (Continue)-Statusmeldung erwartet. Ein User Agent KANN unerwartete 1xx-Antworten ignorieren.

Ein Proxy MUSS 1xx-Antworten weiterleiten, es sei denn, der Proxy selbst hat die Generierung der 1xx-Antwort angefordert. Wenn ein Proxy beispielsweise ein "Expect: 100-continue"-Feld hinzufügt, wenn er eine Anfrage weiterleitet, muss er die entsprechenden 100 (Continue)-Antworten nicht weiterleiten.

6.2.1. 100 Continue (Fortfahren)

Der 100 (Continue)-Statuscode zeigt an, dass der anfängliche Teil einer Anfrage empfangen wurde und noch nicht vom Server abgelehnt wurde. Der Server beabsichtigt, eine endgültige Antwort zu senden, nachdem die Anfrage vollständig empfangen und bearbeitet wurde.

Wenn die Anfrage ein Expect-Header-Feld enthält, das eine 100-continue-Erwartung enthält, zeigt die 100-Antwort an, dass der Server den Anfrage-Payload-Body empfangen möchte, wie in Section 5.1.1 beschrieben. Der Client sollte mit dem Senden der Anfrage fortfahren und die 100-Antwort verwerfen.

Wenn die Anfrage kein Expect-Header-Feld mit der 100-continue-Erwartung enthielt, kann der Client diese vorläufige Antwort einfach verwerfen.

6.2.2. 101 Switching Protocols (Protokollwechsel)

Der 101 (Switching Protocols)-Statuscode zeigt an, dass der Server die Anfrage des Clients über das Upgrade-Header-Feld (Section 6.7 von [RFC7230]) für eine Änderung des auf dieser Verbindung verwendeten Anwendungsprotokolls versteht und bereit ist, ihr zu folgen. Der Server MUSS ein Upgrade-Header-Feld in der Antwort generieren, das angibt, welche(s) Protokoll(e) unmittelbar nach der Leerzeile, die die 101-Antwort beendet, in Kraft treten.

Es wird angenommen, dass der Server nur dann einem Protokollwechsel zustimmt, wenn dies vorteilhaft ist. Beispielsweise könnte der Wechsel zu einer neueren Version von HTTP gegenüber älteren Versionen vorteilhaft sein, und der Wechsel zu einem Echtzeit-Synchronprotokoll könnte bei der Bereitstellung von Ressourcen, die solche Funktionen verwenden, vorteilhaft sein.

6.3. Successful 2xx (Erfolgreich 2xx)

Die 2xx (Successful)-Klasse von Statuscodes zeigt an, dass die Anfrage des Clients erfolgreich empfangen, verstanden und akzeptiert wurde.

6.3.1. 200 OK

Der 200 (OK)-Statuscode zeigt an, dass die Anfrage erfolgreich war. Die in einer 200-Antwort gesendete Nutzlast hängt von der Anfragemethode ab. Für die von dieser Spezifikation definierten Methoden kann die beabsichtigte Bedeutung der Nutzlast wie folgt zusammengefasst werden:

• GET: eine Darstellung der Zielressource;
• HEAD: dieselbe Darstellung wie GET, aber ohne die Darstellungsdaten;
• POST: eine Darstellung des Status oder der aus der Aktion erhaltenen Ergebnisse;
• PUT, DELETE: eine Darstellung des Aktionsstatus;
• OPTIONS: eine Darstellung der Kommunikationsoptionen;
• TRACE: eine Darstellung der Anfragenachricht, wie sie vom End-Server empfangen wurde.

Abgesehen von Antworten auf CONNECT hat eine 200-Antwort immer eine Nutzlast, obwohl ein Origin-Server EINEN Payload-Body mit einer Länge von Null generieren KANN. Wenn keine Nutzlast gewünscht wird, sollte ein Origin-Server stattdessen 204 (No Content) senden. Für CONNECT ist keine Nutzlast erlaubt, da das erfolgreiche Ergebnis ein Tunnel ist, der unmittelbar nach dem 200-Antwort-Header-Abschnitt beginnt.

Eine 200-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.3.2. 201 Created (Erstellt)

Der 201 (Created)-Statuscode zeigt an, dass die Anfrage erfüllt wurde und zur Erstellung einer oder mehrerer neuer Ressourcen geführt hat. Die durch die Anfrage erstellte primäre Ressource wird entweder durch ein Location-Header-Feld in der Antwort oder, wenn kein Location-Feld empfangen wird, durch die effektive Anfrage-URI identifiziert.

Die 201-Antwort-Nutzlast beschreibt und verlinkt typischerweise zu den erstellten Ressourcen. Siehe Section 7.2 für eine Diskussion der Bedeutung und des Zwecks von Validator-Header-Feldern, wie ETag und Last-Modified, in einer 201-Antwort.

6.3.3. 202 Accepted (Akzeptiert)

Der 202 (Accepted)-Statuscode zeigt an, dass die Anfrage zur Verarbeitung akzeptiert wurde, die Verarbeitung jedoch nicht abgeschlossen ist. Die Anfrage könnte schließlich ausgeführt werden oder nicht, da sie möglicherweise nicht erlaubt ist, wenn die Verarbeitung tatsächlich stattfindet. Es gibt keine Möglichkeit in HTTP, einen Statuscode von einer asynchronen Operation erneut zu senden.

Die 202-Antwort ist absichtlich unverbindlich. Ihr Zweck ist es, einem Server zu ermöglichen, eine Anfrage für einen anderen Prozess (möglicherweise einen Batch-orientierten Prozess, der nur einmal pro Tag ausgeführt wird) zu akzeptieren, ohne dass die Verbindung des User Agents zum Server bestehen bleiben muss, bis der Prozess abgeschlossen ist. Die mit dieser Antwort gesendete Darstellung sollte den aktuellen Status der Anfrage beschreiben und auf einen Statusmonitor verweisen (oder ihn einbetten), der dem Benutzer eine Schätzung geben kann, wann die Anfrage erfüllt wird.

6.3.4. 203 Non-Authoritative Information (Nicht-autoritative Information)

Der 203 (Non-Authoritative Information)-Statuscode zeigt an, dass die Anfrage erfolgreich war, aber die eingeschlossene Nutzlast von einem transformierenden Proxy (Section 5.7.2 von [RFC7230]) von der 200 (OK)-Antwort des Origin-Servers modifiziert wurde. Dieser Statuscode ermöglicht es dem Proxy, Empfänger zu benachrichtigen, wenn eine Transformation angewendet wurde, da dieses Wissen spätere Entscheidungen bezüglich des Inhalts beeinflussen könnte. Beispielsweise könnten zukünftige Cache-Validierungsanfragen für den Inhalt nur entlang desselben Anfragepfads (durch dieselben Proxys) anwendbar sein.

Die 203-Antwort ist ähnlich dem Warning-Code von 214 Transformation Applied (Section 5.5 von [RFC7234]), der den Vorteil hat, auf Antworten mit jedem Statuscode anwendbar zu sein.

Eine 203-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.3.5. 204 No Content (Kein Inhalt)

Der 204 (No Content)-Statuscode zeigt an, dass der Server die Anfrage erfolgreich erfüllt hat und dass im Antwort-Payload-Body kein zusätzlicher Inhalt zu senden ist. Metadaten in den Antwort-Header-Feldern beziehen sich auf die Zielressource und ihre ausgewählte Darstellung, nachdem die angeforderte Aktion angewendet wurde.

Wenn beispielsweise ein 204-Statuscode als Antwort auf eine PUT-Anfrage empfangen wird und die Antwort ein ETag-Header-Feld enthält, war das PUT erfolgreich, und der ETag-Feldwert enthält das Entity-Tag für die neue Darstellung dieser Zielressource.

Die 204-Antwort ermöglicht es einem Server anzuzeigen, dass die Aktion erfolgreich auf die Zielressource angewendet wurde, während gleichzeitig impliziert wird, dass der User Agent seine aktuelle "Dokumentenansicht" (falls vorhanden) nicht verlassen muss. Der Server geht davon aus, dass der User Agent seinem Benutzer entsprechend seiner eigenen Schnittstelle eine Anzeige des Erfolgs bereitstellt und alle neuen oder aktualisierten Metadaten in der Antwort auf seine aktive Darstellung anwendet.

Beispielsweise wird ein 204-Statuscode häufig mit Dokumentenbearbeitungsschnittstellen verwendet, die einer "Speichern"-Aktion entsprechen, sodass das gespeicherte Dokument dem Benutzer zur Bearbeitung zur Verfügung steht. Er wird auch häufig mit Schnittstellen verwendet, die erwarten, dass automatisierte Datenübertragungen weit verbreitet sind, wie z. B. in verteilten Versionskontrollsystemen.

Eine 204-Antwort wird durch die erste Leerzeile nach den Header-Feldern beendet, da sie keinen Nachrichtenkörper enthalten kann.

Eine 204-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.3.6. 205 Reset Content (Inhalt zurücksetzen)

Der 205 (Reset Content)-Statuscode zeigt an, dass der Server die Anfrage erfüllt hat und wünscht, dass der User Agent die "Dokumentenansicht", die die Anfrage verursacht hat, auf ihren ursprünglichen Zustand zurücksetzt, wie er vom Origin-Server empfangen wurde.

Diese Antwort soll einen gängigen Dateneingabe-Anwendungsfall unterstützen, bei dem der Benutzer Inhalte erhält, die Dateneingabe unterstützen (ein Formular, Notizblock, Leinwand usw.), Daten in diesem Bereich eingibt oder manipuliert, die eingegebenen Daten in einer Anfrage übermittelt werden und dann der Dateneingabemechanismus für die nächste Eingabe zurückgesetzt wird, sodass der Benutzer leicht eine weitere Eingabeaktion initiieren kann.

Da der 205-Statuscode impliziert, dass kein zusätzlicher Inhalt bereitgestellt wird, DARF ein Server KEINE Nutzlast in einer 205-Antwort generieren. Mit anderen Worten, ein Server MUSS für eine 205-Antwort eines der folgenden Dinge tun: a) einen Body mit Länge Null für die Antwort angeben, indem er ein Content-Length-Header-Feld mit einem Wert von 0 einschließt; b) eine Nutzlast mit Länge Null für die Antwort angeben, indem er ein Transfer-Encoding-Header-Feld mit einem Wert von chunked und einen Nachrichtenkörper einschließt, der aus einem einzelnen Chunk mit Länge Null besteht; oder c) die Verbindung unmittelbar nach dem Senden der Leerzeile, die den Header-Abschnitt beendet, schließen.

6.4. Redirection 3xx (Umleitung 3xx)

Die 3xx (Redirection)-Klasse von Statuscodes zeigt an, dass der User Agent weitere Maßnahmen ergreifen muss, um die Anfrage zu erfüllen. Wenn ein Location-Header-Feld (Section 7.1.2) bereitgestellt wird, KANN der User Agent seine Anfrage automatisch an die durch den Location-Feldwert referenzierte URI umleiten, auch wenn der spezifische Statuscode nicht verstanden wird. Die automatische Umleitung muss bei Methoden, die nicht als sicher bekannt sind, wie in Section 4.2.1 definiert, vorsichtig durchgeführt werden, da der Benutzer möglicherweise keine unsichere Anfrage umleiten möchte.

Es gibt mehrere Arten von Umleitungen:

1. Umleitungen, die angeben, dass die Ressource möglicherweise unter einer anderen URI verfügbar ist, wie durch das Location-Feld angegeben, wie bei den Statuscodes 301 (Moved Permanently), 302 (Found) und 307 (Temporary Redirect).

2. Umleitung, die eine Auswahl übereinstimmender Ressourcen bietet, die jeweils das ursprüngliche Anfrageziel darstellen können, wie beim 300 (Multiple Choices)-Statuscode.

3. Umleitung zu einer anderen Ressource, die durch das Location-Feld identifiziert wird, die eine indirekte Antwort auf die Anfrage darstellen kann, wie beim 303 (See Other)-Statuscode.

4. Umleitung zu einem zuvor zwischengespeicherten Ergebnis, wie beim 304 (Not Modified)-Statuscode.

Hinweis: In HTTP/1.0 wurden die Statuscodes 301 (Moved Permanently) und 302 (Found) für den ersten Typ der Umleitung definiert ([RFC1945], Section 9.3). Frühe User Agents waren gespalten darüber, ob die auf das Umleitungsziel angewendete Methode dieselbe wie die ursprüngliche Anfrage sein oder als GET umgeschrieben werden würde. Obwohl HTTP ursprünglich die erstere Semantik für 301 und 302 definierte (um seiner ursprünglichen Implementierung am CERN zu entsprechen) und 303 (See Other) definierte, um der letzteren Semantik zu entsprechen, konvergierte die vorherrschende Praxis allmählich auch für 301 und 302 zur letzteren Semantik. Die erste Revision von HTTP/1.1 fügte 307 (Temporary Redirect) hinzu, um die erstere Semantik anzuzeigen, ohne von abweichender Praxis beeinflusst zu werden. Mehr als 10 Jahre später schreiben die meisten User Agents die Methode für 301 und 302 immer noch um; daher macht diese Spezifikation dieses Verhalten konform, wenn die ursprüngliche Anfrage POST ist.

Ein Client SOLLTE zyklische Umleitungen (d. h. "unendliche" Umleitungsschleifen) erkennen und eingreifen.

Hinweis: Eine frühere Version dieser Spezifikation empfahl maximal fünf Umleitungen ([RFC2068], Section 10.3). Inhaltsersteller müssen sich bewusst sein, dass einige Clients möglicherweise eine solche feste Begrenzung implementieren.

6.4.1. 300 Multiple Choices (Mehrere Auswahlmöglichkeiten)

Der 300 (Multiple Choices)-Statuscode zeigt an, dass die Zielressource mehr als eine Darstellung hat, jede mit ihrem eigenen spezifischeren Bezeichner, und Informationen über die Alternativen bereitgestellt werden, damit der Benutzer (oder User Agent) eine bevorzugte Darstellung auswählen kann, indem er seine Anfrage an einen oder mehrere dieser Bezeichner umleitet. Mit anderen Worten, der Server wünscht, dass der User Agent sich an reaktiver Verhandlung beteiligt, um die am besten geeignete(n) Darstellung(en) für seine Bedürfnisse auszuwählen (Section 3.4.2).

Wenn der Server eine bevorzugte Wahl hat, SOLLTE der Server ein Location-Header-Feld generieren, das eine URI-Referenz der bevorzugten Wahl enthält. Der User Agent KANN den Location-Feldwert für die automatische Umleitung verwenden.

Für andere Anfragemethoden als HEAD SOLLTE der Server eine Nutzlast in der 300-Antwort generieren, die eine Liste von Darstellungsmetadaten und URI-Referenz(en) enthält, aus denen der Benutzer oder User Agent die bevorzugteste auswählen kann. Der User Agent KANN eine Auswahl aus dieser Liste automatisch treffen, wenn er den bereitgestellten Medientyp versteht. Ein spezifisches Format für die automatische Auswahl ist nicht durch diese Spezifikation definiert, da HTTP versucht, orthogonal zur Definition seiner Nutzlasten zu bleiben. In der Praxis wird die Darstellung in einem leicht zu analysierenden Format bereitgestellt, das als für den User Agent akzeptabel angesehen wird, wie durch gemeinsames Design oder Inhaltsverhandlung bestimmt, oder in einem allgemein akzeptierten Hypertext-Format.

Eine 300-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

Hinweis: Der ursprüngliche Vorschlag für den 300-Statuscode definierte das URI-Header-Feld als eine Liste alternativer Darstellungen, sodass es für 200-, 300- und 406-Antworten verwendbar wäre und in Antworten auf die HEAD-Methode übertragen werden könnte. Mangelnde Implementierung und Meinungsverschiedenheiten über die Syntax führten jedoch dazu, dass sowohl URI als auch Alternates (ein späterer Vorschlag) aus dieser Spezifikation entfernt wurden. Es ist möglich, die Liste mit einem Satz von Link-Header-Feldern [RFC5988] zu kommunizieren, jeweils mit einer Beziehung von "alternate", obwohl die Implementierung ein Henne-Ei-Problem ist.

6.4.2. 301 Moved Permanently (Dauerhaft verschoben)

Der 301 (Moved Permanently)-Statuscode zeigt an, dass der Zielressource eine neue permanente URI zugewiesen wurde und alle zukünftigen Verweise auf diese Ressource eine der eingeschlossenen URIs verwenden sollten. Clients mit Link-Bearbeitungsfähigkeiten sollten Verweise auf die effektive Anfrage-URI automatisch auf eine oder mehrere der neuen vom Server gesendeten Referenzen neu verlinken, wo möglich.

Der Server SOLLTE ein Location-Header-Feld in der Antwort generieren, das eine bevorzugte URI-Referenz für die neue permanente URI enthält. Der User Agent KANN den Location-Feldwert für die automatische Umleitung verwenden. Die Antwort-Nutzlast des Servers enthält normalerweise eine kurze Hypertext-Notiz mit einem Hyperlink zu der/den neuen URI(s).

Hinweis: Aus historischen Gründen KANN ein User Agent die Anfragemethode von POST zu GET für die nachfolgende Anfrage ändern. Wenn dieses Verhalten nicht erwünscht ist, kann stattdessen der 307 (Temporary Redirect)-Statuscode verwendet werden.

Eine 301-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.4.3. 302 Found (Gefunden)

Der 302 (Found)-Statuscode zeigt an, dass die Zielressource sich vorübergehend unter einer anderen URI befindet. Da die Umleitung gelegentlich geändert werden kann, sollte der Client weiterhin die effektive Anfrage-URI für zukünftige Anfragen verwenden.

Der Server SOLLTE ein Location-Header-Feld in der Antwort generieren, das eine URI-Referenz für die andere URI enthält. Der User Agent KANN den Location-Feldwert für die automatische Umleitung verwenden. Die Antwort-Nutzlast des Servers enthält normalerweise eine kurze Hypertext-Notiz mit einem Hyperlink zu der/den anderen URI(s).

Hinweis: Aus historischen Gründen KANN ein User Agent die Anfragemethode von POST zu GET für die nachfolgende Anfrage ändern. Wenn dieses Verhalten nicht erwünscht ist, kann stattdessen der 307 (Temporary Redirect)-Statuscode verwendet werden.

6.4.4. 303 See Other (Siehe Andere)

Der 303 (See Other)-Statuscode zeigt an, dass der Server den User Agent zu einer anderen Ressource umleitet, wie durch eine URI im Location-Header-Feld angegeben, die eine indirekte Antwort auf die ursprüngliche Anfrage bereitstellen soll. Ein User Agent kann eine Abrufanfrage für diese URI durchführen (eine GET- oder HEAD-Anfrage bei Verwendung von HTTP), die ebenfalls umgeleitet werden könnte, und das endgültige Ergebnis als Antwort auf die ursprüngliche Anfrage präsentieren. Beachten Sie, dass die neue URI im Location-Header-Feld nicht als äquivalent zur effektiven Anfrage-URI angesehen wird.

Dieser Statuscode ist auf jede HTTP-Methode anwendbar. Er wird hauptsächlich verwendet, um die Ausgabe einer POST-Aktion zu ermöglichen, den User Agent zu einer ausgewählten Ressource umzuleiten, da dies die der POST-Antwort entsprechenden Informationen in einer Form bereitstellt, die separat identifiziert, mit Lesezeichen versehen und gecacht werden kann, unabhängig von der ursprünglichen Anfrage.

Eine 303-Antwort auf eine GET-Anfrage zeigt an, dass der Origin-Server keine Darstellung der Zielressource hat, die vom Server über HTTP übertragen werden kann. Das Location-Feldwert bezieht sich jedoch auf eine Ressource, die die Zielressource beschreibt, sodass eine Abrufanfrage für diese andere Ressource zu einer Darstellung führen könnte, die für Empfänger nützlich ist, ohne zu implizieren, dass sie die ursprüngliche Zielressource darstellt. Beachten Sie, dass Antworten auf die Fragen, was dargestellt werden kann, welche Darstellungen angemessen sind und was eine nützliche Beschreibung sein könnte, außerhalb des Umfangs von HTTP liegen.

Außer bei Antworten auf eine HEAD-Anfrage sollte die Darstellung einer 303-Antwort eine kurze Hypertext-Notiz mit einem Hyperlink zu derselben im Location-Header-Feld bereitgestellten URI-Referenz enthalten.

6.4.5. 305 Use Proxy (Proxy verwenden)

Der 305 (Use Proxy)-Statuscode wurde in einer früheren Version dieser Spezifikation definiert und ist jetzt veraltet (Anhang B).

6.4.6. 306 (Unused / Unbenutzt)

Der 306-Statuscode wurde in einer früheren Version dieser Spezifikation definiert, wird nicht mehr verwendet, und der Code ist reserviert.

6.4.7. 307 Temporary Redirect (Temporäre Umleitung)

Der 307 (Temporary Redirect)-Statuscode zeigt an, dass die Zielressource sich vorübergehend unter einer anderen URI befindet und der User Agent die Anfragemethode NICHT ändern DARF, wenn er eine automatische Umleitung zu dieser URI durchführt. Da sich die Umleitung im Laufe der Zeit ändern kann, sollte der Client weiterhin die ursprüngliche effektive Anfrage-URI für zukünftige Anfragen verwenden.

Der Server SOLLTE ein Location-Header-Feld in der Antwort generieren, das eine URI-Referenz für die andere URI enthält. Der User Agent KANN den Location-Feldwert für die automatische Umleitung verwenden. Die Antwort-Nutzlast des Servers enthält normalerweise eine kurze Hypertext-Notiz mit einem Hyperlink zu der/den anderen URI(s).

Hinweis: Dieser Statuscode ist ähnlich wie 302 (Found), außer dass er das Ändern der Anfragemethode von POST zu GET nicht erlaubt. Diese Spezifikation definiert kein äquivalentes Gegenstück für 301 (Moved Permanently) ([RFC7538] definiert jedoch den Statuscode 308 (Permanent Redirect) für diesen Zweck).

6.5. Client Error 4xx (Client-Fehler 4xx)

Die 4xx (Client Error)-Klasse von Statuscodes zeigt an, dass der Client einen Fehler gemacht zu haben scheint. Außer bei Antworten auf eine HEAD-Anfrage SOLLTE der Server eine Darstellung senden, die eine Erklärung der Fehlersituation enthält und ob es sich um eine temporäre oder permanente Bedingung handelt. Diese Statuscodes sind auf jede Anfragemethode anwendbar. User Agents SOLLTEN jede enthaltene Darstellung dem Benutzer anzeigen.

6.5.1. 400 Bad Request (Fehlerhafte Anfrage)

Der 400 (Bad Request)-Statuscode zeigt an, dass der Server die Anfrage aufgrund von etwas, das als Client-Fehler wahrgenommen wird (z. B. fehlerhafte Anfrage-Syntax, ungültiges Anfragenachrichten-Framing oder täuschendes Anfrage-Routing), nicht verarbeiten kann oder will.

6.5.2. 402 Payment Required (Zahlung erforderlich)

Der 402 (Payment Required)-Statuscode ist für zukünftige Verwendung reserviert.

6.5.3. 403 Forbidden (Verboten)

Der 403 (Forbidden)-Statuscode zeigt an, dass der Server die Anfrage verstanden hat, sich aber weigert, sie zu autorisieren. Ein Server, der öffentlich machen möchte, warum die Anfrage verboten wurde, kann diesen Grund in der Antwort-Nutzlast (falls vorhanden) beschreiben.

Wenn Authentifizierungsinformationen in der Anfrage bereitgestellt wurden, hält der Server diese für unzureichend, um Zugriff zu gewähren. Der Client SOLLTE die Anfrage NICHT automatisch mit denselben Anmeldeinformationen wiederholen. Der Client KANN die Anfrage mit neuen oder anderen Anmeldeinformationen wiederholen. Eine Anfrage könnte jedoch aus Gründen verboten sein, die nichts mit den Anmeldeinformationen zu tun haben.

Ein Origin-Server, der die aktuelle Existenz einer verbotenen Zielressource "verbergen" möchte, KANN stattdessen mit einem Statuscode von 404 (Not Found) antworten.

6.5.4. 404 Not Found (Nicht gefunden)

Der 404 (Not Found)-Statuscode zeigt an, dass der Origin-Server keine aktuelle Darstellung für die Zielressource gefunden hat oder nicht bereit ist, preiszugeben, dass eine existiert. Ein 404-Statuscode zeigt nicht an, ob dieses Fehlen einer Darstellung temporär oder permanent ist; der 410 (Gone)-Statuscode wird 404 vorgezogen, wenn der Origin-Server weiß, vermutlich durch irgendwelche konfigurierbaren Mittel, dass die Bedingung wahrscheinlich permanent ist.

Eine 404-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.5.5. 405 Method Not Allowed (Methode nicht erlaubt)

Der 405 (Method Not Allowed)-Statuscode zeigt an, dass die in der Anfragezeile empfangene Methode vom Origin-Server erkannt, aber von der Zielressource nicht unterstützt wird. Der Origin-Server MUSS ein Allow-Header-Feld in einer 405-Antwort generieren, das eine Liste der aktuell von der Zielressource unterstützten Methoden enthält.

Eine 405-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.5.6. 406 Not Acceptable (Nicht akzeptabel)

Der 406 (Not Acceptable)-Statuscode zeigt an, dass die Zielressource keine aktuelle Darstellung hat, die für den User Agent gemäß den in der Anfrage empfangenen proaktiven Verhandlungs-Header-Feldern (Section 5.3) akzeptabel wäre, und der Server nicht bereit ist, eine Standarddarstellung bereitzustellen.

Der Server SOLLTE eine Nutzlast generieren, die eine Liste verfügbarer Darstellungsmerkmale und entsprechender Ressourcenbezeichner enthält, aus denen der Benutzer oder User Agent die am besten geeignete auswählen kann. Ein User Agent KANN die am besten geeignete Wahl aus dieser Liste automatisch auswählen. Diese Spezifikation definiert jedoch keinen Standard für eine solche automatische Auswahl, wie in Section 6.4.1 beschrieben.

6.5.7. 408 Request Timeout (Anfrage-Timeout)

Der 408 (Request Timeout)-Statuscode zeigt an, dass der Server innerhalb der Zeit, die er bereit war zu warten, keine vollständige Anfragenachricht erhalten hat. Ein Server SOLLTE die "close"-Verbindungsoption (Section 6.1 von [RFC7230]) in der Antwort senden, da 408 impliziert, dass der Server beschlossen hat, die Verbindung zu schließen, anstatt weiter zu warten. Wenn der Client eine ausstehende Anfrage in Übertragung hat, KANN der Client diese Anfrage auf einer neuen Verbindung wiederholen.

6.5.8. 409 Conflict (Konflikt)

Der 409 (Conflict)-Statuscode zeigt an, dass die Anfrage aufgrund eines Konflikts mit dem aktuellen Zustand der Zielressource nicht abgeschlossen werden konnte. Dieser Code wird in Situationen verwendet, in denen der Benutzer möglicherweise in der Lage ist, den Konflikt zu lösen und die Anfrage erneut zu senden. Der Server SOLLTE eine Nutzlast generieren, die genügend Informationen enthält, damit ein Benutzer die Quelle des Konflikts erkennen kann.

Konflikte treten am wahrscheinlichsten als Antwort auf eine PUT-Anfrage auf. Wenn beispielsweise Versionierung verwendet wird und die PUT-Darstellung Änderungen an einer Ressource enthält, die mit den von einer früheren (Drittanbieter-) Anfrage vorgenommenen Änderungen in Konflikt stehen, könnte der Origin-Server eine 409-Antwort verwenden, um anzuzeigen, dass er die Anfrage nicht abschließen kann. In diesem Fall würde die Antwort-Darstellung wahrscheinlich Informationen enthalten, die beim Zusammenführen der Unterschiede basierend auf der Revisionsgeschichte nützlich sind.

6.5.9. 410 Gone (Verschwunden)

Der 410 (Gone)-Statuscode zeigt an, dass der Zugriff auf die Zielressource auf dem Origin-Server nicht mehr verfügbar ist und diese Bedingung wahrscheinlich permanent ist. Wenn der Origin-Server nicht weiß oder keine Möglichkeit hat zu bestimmen, ob die Bedingung permanent ist oder nicht, sollte stattdessen der Statuscode 404 (Not Found) verwendet werden.

Die 410-Antwort soll hauptsächlich die Aufgabe der Web-Wartung unterstützen, indem sie dem Empfänger mitteilt, dass die Ressource absichtlich nicht verfügbar ist und die Servereigentümer wünschen, dass entfernte Links zu dieser Ressource entfernt werden. Ein solches Ereignis ist üblich für zeitlich begrenzte, werbliche Dienste und für Ressourcen, die Personen gehören, die nicht mehr mit der Site des Origin-Servers verbunden sind. Es ist nicht erforderlich, alle dauerhaft nicht verfügbaren Ressourcen als "gone" zu markieren oder die Markierung für eine bestimmte Zeitdauer aufrechtzuerhalten -- dies liegt im Ermessen des Servereigentümers.

Eine 410-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.5.10. 411 Length Required (Länge erforderlich)

Der 411 (Length Required)-Statuscode zeigt an, dass der Server sich weigert, die Anfrage ohne einen definierten Content-Length (Section 3.3.2 von [RFC7230]) zu akzeptieren. Der Client KANN die Anfrage wiederholen, wenn er ein gültiges Content-Length-Header-Feld hinzufügt, das die Länge des Nachrichtenkörpers in der Anfragenachricht enthält.

6.5.11. 413 Payload Too Large (Nutzlast zu groß)

Der 413 (Payload Too Large)-Statuscode zeigt an, dass der Server sich weigert, eine Anfrage zu verarbeiten, weil die Anfrage-Nutzlast größer ist, als der Server bereit oder in der Lage ist zu verarbeiten. Der Server KANN die Verbindung schließen, um zu verhindern, dass der Client die Anfrage fortsetzt.

Wenn die Bedingung temporär ist, SOLLTE der Server ein Retry-After-Header-Feld generieren, um anzuzeigen, dass sie temporär ist und nach welcher Zeit der Client es erneut versuchen KANN.

6.5.12. 414 URI Too Long (URI zu lang)

Der 414 (URI Too Long)-Statuscode zeigt an, dass der Server sich weigert, die Anfrage zu bedienen, weil das Anfrageziel (Section 5.3 von [RFC7230]) länger ist, als der Server bereit ist zu interpretieren. Diese seltene Bedingung tritt wahrscheinlich nur auf, wenn ein Client eine POST-Anfrage unsachgemäß in eine GET-Anfrage mit langen Abfrageinformationen umgewandelt hat, wenn der Client in ein "schwarzes Loch" der Umleitung abgestiegen ist (z. B. ein umgeleitetes URI-Präfix, das auf ein Suffix von sich selbst zeigt), oder wenn der Server von einem Client angegriffen wird, der versucht, Sicherheitslücken auszunutzen.

Eine 414-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.5.13. 415 Unsupported Media Type (Nicht unterstützter Medientyp)

Der 415 (Unsupported Media Type)-Statuscode zeigt an, dass der Origin-Server sich weigert, die Anfrage zu bedienen, weil die Nutzlast in einem Format vorliegt, das von dieser Methode auf der Zielressource nicht unterstützt wird. Das Formatproblem könnte auf den von der Anfrage angegebenen Content-Type oder Content-Encoding zurückzuführen sein oder das Ergebnis der direkten Inspektion der Daten sein.

6.5.14. 417 Expectation Failed (Erwartung fehlgeschlagen)

Der 417 (Expectation Failed)-Statuscode zeigt an, dass die im Expect-Header-Feld der Anfrage (Section 5.1.1) angegebene Erwartung von mindestens einem der eingehenden Server nicht erfüllt werden konnte.

6.5.15. 426 Upgrade Required (Upgrade erforderlich)

Der 426 (Upgrade Required)-Statuscode zeigt an, dass der Server sich weigert, die Anfrage mit dem aktuellen Protokoll auszuführen, aber möglicherweise bereit ist, dies zu tun, nachdem der Client auf ein anderes Protokoll aktualisiert hat. Der Server MUSS ein Upgrade-Header-Feld in einer 426-Antwort senden, um das/die erforderliche(n) Protokoll(e) anzuzeigen (Section 6.7 von [RFC7230]).

Beispiel:

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

6.6. Server Error 5xx (Server-Fehler 5xx)

Die 5xx (Server Error)-Klasse von Statuscodes zeigt an, dass der Server sich bewusst ist, dass er einen Fehler gemacht hat oder nicht in der Lage ist, die angeforderte Methode auszuführen. Außer bei Antworten auf eine HEAD-Anfrage SOLLTE der Server eine Darstellung senden, die eine Erklärung der Fehlersituation enthält und ob es sich um eine temporäre oder permanente Bedingung handelt. Ein User Agent SOLLTE jede enthaltene Darstellung dem Benutzer anzeigen. Diese Statuscodes sind auf jede Anfragemethode anwendbar.

6.6.1. 500 Internal Server Error (Interner Server-Fehler)

Der 500 (Internal Server Error)-Statuscode zeigt an, dass der Server auf eine unerwartete Bedingung gestoßen ist, die ihn daran hinderte, die Anfrage zu erfüllen.

6.6.2. 501 Not Implemented (Nicht implementiert)

Der 501 (Not Implemented)-Statuscode zeigt an, dass der Server die zur Erfüllung der Anfrage erforderliche Funktionalität nicht unterstützt. Dies ist die angemessene Antwort, wenn der Server die Anfragemethode nicht erkennt und nicht in der Lage ist, sie für irgendeine Ressource zu unterstützen.

Eine 501-Antwort ist standardmäßig cachefähig; d. h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerung angegeben (siehe Section 4.2.2 von [RFC7234]).

6.6.3. 502 Bad Gateway (Fehlerhaftes Gateway)

Der 502 (Bad Gateway)-Statuscode zeigt an, dass der Server, während er als Gateway oder Proxy fungierte, eine ungültige Antwort von einem eingehenden Server erhalten hat, auf den er beim Versuch, die Anfrage zu erfüllen, zugegriffen hat.

6.6.4. 503 Service Unavailable (Dienst nicht verfügbar)

Der 503 (Service Unavailable)-Statuscode zeigt an, dass der Server derzeit aufgrund einer vorübergehenden Überlastung oder geplanten Wartung nicht in der Lage ist, die Anfrage zu bearbeiten, was wahrscheinlich nach einiger Verzögerung behoben wird. Der Server KANN ein Retry-After-Header-Feld (Section 7.1.3) senden, um eine angemessene Zeit vorzuschlagen, die der Client warten sollte, bevor er die Anfrage wiederholt.

Hinweis: Das Vorhandensein des 503-Statuscodes impliziert nicht, dass ein Server ihn verwenden muss, wenn er überlastet wird. Einige Server könnten einfach die Verbindung ablehnen.

6.6.5. 504 Gateway Timeout (Gateway-Timeout)

Der 504 (Gateway Timeout)-Statuscode zeigt an, dass der Server, während er als Gateway oder Proxy fungierte, keine rechtzeitige Antwort von einem Upstream-Server erhalten hat, auf den er zugreifen musste, um die Anfrage abzuschließen.

6.6.6. 505 HTTP Version Not Supported (HTTP-Version nicht unterstützt)

Der 505 (HTTP Version Not Supported)-Statuscode zeigt an, dass der Server die Hauptversion von HTTP, die in der Anfragenachricht verwendet wurde, nicht unterstützt oder sich weigert zu unterstützen. Der Server gibt an, dass er nicht in der Lage oder nicht bereit ist, die Anfrage mit derselben Hauptversion wie der Client abzuschließen, wie in Section 2.6 von [RFC7230] beschrieben, außer mit dieser Fehlermeldung. Der Server SOLLTE eine Darstellung generieren, die eine Erklärung enthält, warum diese Version nicht unterstützt wird und welche anderen Protokolle von diesem Server unterstützt werden.

---