15. Status Codes (Statuscodes)

Der Statuscode einer Antwort ist ein dreistelliger ganzzahliger Code, der das Ergebnis der Anfrage und die Semantik der Antwort beschreibt, einschließlich ob die Anfrage erfolgreich war und welcher Inhalt enthalten ist (falls vorhanden). Alle gültigen Statuscodes liegen im Bereich von 100 bis 599 einschließlich.

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): Die Anfrage wurde empfangen, Verarbeitung wird fortgesetzt
2xx (Successful): Die Anfrage wurde erfolgreich empfangen, verstanden und akzeptiert
3xx (Redirection): Weitere Maßnahmen müssen ergriffen werden, um die Anfrage abzuschließen
4xx (Client Error): Die Anfrage enthält fehlerhafte Syntax oder kann nicht erfüllt werden
5xx (Server Error): Der Server konnte eine offensichtlich gültige Anfrage nicht erfüllen

HTTP-Statuscodes sind erweiterbar. Ein Client muss nicht die Bedeutung aller registrierten Statuscodes verstehen, obwohl ein solches Verständnis offensichtlich wünschenswert ist. Allerdings MUSS ein Client die Klasse eines jeden Statuscodes verstehen, wie durch die erste Ziffer angezeigt, und einen nicht erkannten Statuscode als gleichwertig zum x00-Statuscode dieser Klasse behandeln.

Wenn ein Client beispielsweise einen nicht erkannten Statuscode 471 erhält, kann er an der ersten Ziffer erkennen, dass mit seiner Anfrage etwas nicht stimmte, 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.

Werte außerhalb des Bereichs 100..599 sind ungültig. Implementierungen verwenden oft dreistellige ganzzahlige Werte außerhalb dieses Bereichs (d.h. 600..999) für die interne Kommunikation von Nicht-HTTP-Status (z.B. Bibliotheksfehler). Ein Client, der eine Antwort mit einem ungültigen Statuscode erhält, SOLLTE die Antwort so verarbeiten, als hätte sie einen 5xx (Server Error) Statuscode.

Eine einzelne Anfrage kann mehrere zugehörige Antworten haben: null oder mehr "Zwischen"-Antworten (nicht-final) mit Statuscodes im "informational" (1xx) Bereich, gefolgt von genau einer "finalen" Antwort mit einem Statuscode in einem der anderen Bereiche.

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

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

Antworten mit Statuscodes, die als heuristisch cachebar definiert sind (z.B. 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 und 501 in dieser Spezifikation), können von einem Cache mit heuristischem Ablauf wiederverwendet werden, sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben [CACHING]; alle anderen Statuscodes sind nicht heuristisch cachebar.

Zusätzliche Statuscodes, die außerhalb des Geltungsbereichs dieser Spezifikation liegen, wurden für die Verwendung in HTTP spezifiziert. Alle derartigen Statuscodes sollten in der "Hypertext Transfer Protocol (HTTP) Status Code Registry" registriert werden, wie in Abschnitt 16.2 beschrieben.

15.2. Informational 1xx

Die 1xx (Informational) Klasse von Statuscodes zeigt eine Zwischenantwort zur Kommunikation des Verbindungsstatus oder des Anfragenfortschritts an, bevor die angeforderte Aktion abgeschlossen und eine finale Antwort gesendet wird. Da HTTP/1.0 keine 1xx Statuscodes definierte, DARF ein Server KEINE 1xx-Antwort an einen HTTP/1.0-Client senden.

Eine 1xx-Antwort wird durch das Ende des Header-Bereichs beendet; sie kann keinen Inhalt oder Trailer enthalten.

Ein Client MUSS in der Lage sein, eine oder mehrere 1xx-Antworten zu parsen, die vor einer finalen Antwort empfangen werden, auch wenn der Client keine erwartet. Ein User-Agent DARF unerwartete 1xx-Antworten ignorieren.

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

15.2.1. 100 Continue

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 finale Antwort zu senden, nachdem die Anfrage vollständig empfangen und bearbeitet wurde.

Wenn die Anfrage ein Expect-Headerfeld enthält, das eine 100-continue-Erwartung beinhaltet, zeigt die 100-Antwort an, dass der Server den Anfrageinhalt empfangen möchte, wie in Abschnitt 10.1.1 beschrieben. Der Client sollte die Anfrage weiter senden und die 100-Antwort verwerfen.

Wenn die Anfrage kein Expect-Headerfeld mit der 100-continue-Erwartung enthielt, kann der Client diese Zwischenantwort einfach verwerfen.

15.2.2. 101 Switching Protocols

Der 101 (Switching Protocols) Statuscode zeigt an, dass der Server die Anfrage des Clients über das Upgrade-Headerfeld (Abschnitt 7.8) versteht und bereit ist, sie zu erfüllen, um das auf dieser Verbindung verwendete Anwendungsprotokoll zu ändern. Der Server MUSS ein Upgrade-Headerfeld in der Antwort generieren, das angibt, welches/welche Protokoll(e) nach dieser Antwort wirksam sein werden.

Es wird angenommen, dass der Server nur dann zustimmt, Protokolle zu wechseln, wenn es vorteilhaft ist. Beispielsweise könnte das Wechseln zu einer neueren HTTP-Version gegenüber älteren Versionen von Vorteil sein, und das Wechseln zu einem Echtzeit-Synchronisationsprotokoll könnte bei der Bereitstellung von Ressourcen, die solche Funktionen nutzen, von Vorteil sein.

15.3. Successful 2xx

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

15.3.1. 200 OK

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

Request Method	Response content is a representation of:
GET	the target resource
HEAD	the target resource, like GET, but without
	transferring the representation data
POST	the status of, or results obtained from,
	the action
PUT, DELETE	the status of the action
OPTIONS	communication options for the target
	resource
TRACE	the request message as received by the
	server returning the trace

Tabelle 6

Abgesehen von Antworten auf CONNECT wird erwartet, dass eine 200-Antwort Nachrichteninhalt enthält, es sei denn, die Nachrichtenrahmung gibt ausdrücklich an, dass der Inhalt eine Länge von Null hat. Wenn ein Aspekt der Anfrage eine Präferenz für keinen Inhalt bei Erfolg anzeigt, sollte der Ursprungsserver stattdessen eine 204 (No Content) Antwort senden. Für CONNECT gibt es keinen Inhalt, da das erfolgreiche Ergebnis ein Tunnel ist, der unmittelbar nach dem 200-Antwort-Header-Bereich beginnt.

Eine 200-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

In 200-Antworten auf GET oder HEAD SOLLTE ein Ursprungsserver alle verfügbaren Validatorfelder (Abschnitt 8.8) für die ausgewählte Darstellung senden, wobei sowohl ein starkes Entity-Tag als auch ein Last-Modified-Datum bevorzugt werden.

In 200-Antworten auf zustandsändernde Methoden vermitteln alle in der Antwort gesendeten Validatorfelder (Abschnitt 8.8) die aktuellen Validatoren für die neue Darstellung, die als Ergebnis der erfolgreichen Anwendung der Anfragenssemantik gebildet wurde. Beachten Sie, dass die PUT-Methode (Abschnitt 9.3.4) zusätzliche Anforderungen hat, die das Senden solcher Validatoren ausschließen könnten.

15.3.2. 201 Created

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-Headerfeld in der Antwort oder, wenn kein Location-Headerfeld empfangen wird, durch die Ziel-URI identifiziert.

Der 201-Antwortinhalt beschreibt normalerweise und verlinkt zu den erstellten Ressourcen. Alle in der Antwort gesendeten Validatorfelder (Abschnitt 8.8) vermitteln die aktuellen Validatoren für eine neue Darstellung, die durch die Anfrage erstellt wurde. Beachten Sie, dass die PUT-Methode (Abschnitt 9.3.4) zusätzliche Anforderungen hat, die das Senden solcher Validatoren ausschließen könnten.

15.3.3. 202 Accepted

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

Die 202-Antwort ist absichtlich unverbindlich. Ihr Zweck besteht darin, es einem Server zu ermöglichen, eine Anfrage für einen anderen Prozess (vielleicht 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 diesen einbetten), der dem Benutzer eine Schätzung darüber liefern kann, wann die Anfrage erfüllt wird.

15.3.4. 203 Non-Authoritative Information

Der 203 (Non-Authoritative Information) Statuscode zeigt an, dass die Anfrage erfolgreich war, der beigefügte Inhalt jedoch von einem transformierenden Proxy aus der 200 (OK) Antwort des Ursprungsservers modifiziert wurde (Abschnitt 7.7). 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.

Eine 203-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.3.5. 204 No Content

Der 204 (No Content) Statuscode zeigt an, dass der Server die Anfrage erfolgreich erfüllt hat und dass kein zusätzlicher Inhalt im Antwortinhalt zu senden ist. Metadaten in den Antwort-Headerfeldern 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-Feld enthält, war der 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 impliziert wird, dass der User-Agent nicht von seiner aktuellen "Dokumentansicht" (falls vorhanden) wegnavigieren muss. Der Server geht davon aus, dass der User-Agent dem Benutzer eine Anzeige des Erfolgs gemäß seiner eigenen Schnittstelle bereitstellt und alle neuen oder aktualisierten Metadaten in der Antwort auf seine aktive Darstellung anwendet.

Beispielsweise wird ein 204-Statuscode häufig bei Dokumentbearbeitungsschnittstellen verwendet, die einer "Speichern"-Aktion entsprechen, sodass das zu speichernde Dokument dem Benutzer zum Bearbeiten zur Verfügung bleibt. Es wird auch häufig bei Schnittstellen verwendet, die erwarten, dass automatisierte Datenübertragungen vorherrschen, wie innerhalb verteilter Versionskontrollsysteme.

Eine 204-Antwort wird durch das Ende des Header-Bereichs beendet; sie kann keinen Inhalt oder Trailer enthalten.

Eine 204-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.3.6. 205 Reset Content

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

Diese Antwort soll einen häufigen Dateneingabe-Anwendungsfall unterstützen, bei dem der Benutzer Inhalte erhält, die die Dateneingabe unterstützen (ein Formular, Notizblock, Zeichenfläche usw.), Daten in diesem Bereich eingibt oder manipuliert, bewirkt, dass die eingegebenen Daten in einer Anfrage übermittelt werden, und dann wird der Dateneingabemechanismus für den nächsten Eintrag zurückgesetzt, sodass der Benutzer leicht eine weitere Eingabeaktion initiieren kann.

Da der 205-Statuscode impliziert, dass kein zusätzlicher Inhalt bereitgestellt wird, DARF ein Server KEINEN Inhalt in einer 205-Antwort generieren.

15.3.7. 206 Partial Content

Der 206 (Partial Content) Statuscode zeigt an, dass der Server eine Bereichsanfrage für die Zielressource erfolgreich erfüllt, indem er einen oder mehrere Teile der ausgewählten Darstellung überträgt.

Ein Server, der Bereichsanfragen unterstützt (Abschnitt 14), wird normalerweise versuchen, alle angeforderten Bereiche zu erfüllen, da das Senden von weniger Daten wahrscheinlich zu einer weiteren Client-Anfrage für den Rest führen wird. Ein Server möchte jedoch möglicherweise aus eigenen Gründen nur eine Teilmenge der angeforderten Daten senden, wie vorübergehende Nichtverfügbarkeit, Cache-Effizienz, Lastausgleich usw. Da eine 206-Antwort selbstbeschreibend ist, kann der Client immer noch eine Antwort verstehen, die seine Bereichsanfrage nur teilweise erfüllt.

Ein Client MUSS die Content-Type- und Content-Range-Felder einer 206-Antwort überprüfen, um festzustellen, welche Teile enthalten sind und ob zusätzliche Anfragen erforderlich sind.

Ein Server, der eine 206-Antwort generiert, MUSS die folgenden Headerfelder generieren, zusätzlich zu den in den Unterabschnitten unten erforderlichen, wenn das Feld in einer 200 (OK) Antwort auf dieselbe Anfrage gesendet worden wäre: Date, Cache-Control, ETag, Expires, Content-Location und Vary.

Ein in einer 206-Antwort vorhandenes Content-Length-Headerfeld gibt die Anzahl der Oktette im Inhalt dieser Nachricht an, was normalerweise nicht die vollständige Länge der ausgewählten Darstellung ist. Jedes Content-Range-Headerfeld enthält Informationen über die vollständige Länge der ausgewählten Darstellung.

Ein Sender, der eine 206-Antwort auf eine Anfrage mit einem If-Range-Headerfeld generiert, SOLLTE KEINE anderen Darstellungs-Headerfelder außer den erforderlichen generieren, da der Client bereits eine vorherige Antwort hat, die diese Headerfelder enthält. Andernfalls MUSS ein Sender alle Darstellungs-Headerfelder generieren, die in einer 200 (OK) Antwort auf dieselbe Anfrage gesendet worden wären.

Eine 206-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.3.7.1. Single Part

Wenn ein einzelner Teil übertragen wird, MUSS der Server, der die 206-Antwort generiert, ein Content-Range-Headerfeld generieren, das beschreibt, welcher Bereich der ausgewählten Darstellung eingeschlossen ist, und einen Inhalt, der aus dem Bereich besteht. Beispiel:

HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif

... 26012 bytes of partial image data ...

15.3.7.2. Multiple Parts

Wenn mehrere Teile übertragen werden, MUSS der Server, der die 206-Antwort generiert, "multipart/byteranges"-Inhalt generieren, wie in Abschnitt 14.6 definiert, und ein Content-Type-Headerfeld, das den "multipart/byteranges"-Medientyp und seinen erforderlichen Boundary-Parameter enthält. Um Verwechslungen mit Einzelteil-Antworten zu vermeiden, DARF ein Server KEIN Content-Range-Headerfeld im HTTP-Header-Bereich einer mehrteiligen Antwort generieren (dieses Feld wird stattdessen in jedem Teil gesendet).

Im Header-Bereich jedes Body-Teils im mehrteiligen Inhalt MUSS der Server ein Content-Range-Headerfeld generieren, das dem in diesem Body-Teil eingeschlossenen Bereich entspricht. Wenn die ausgewählte Darstellung in einer 200 (OK) Antwort ein Content-Type-Headerfeld gehabt hätte, SOLLTE der Server dasselbe Content-Type-Headerfeld im Header-Bereich jedes Body-Teils generieren. Beispiel:

HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Length: 1741 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 500-999/8000

...the first range... --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 7000-7999/8000

...the second range --THIS_STRING_SEPARATES--

Wenn mehrere Bereiche angefordert werden, DARF ein Server alle Bereiche zusammenführen, die sich überschneiden oder durch eine Lücke getrennt sind, die kleiner ist als der Overhead beim Senden mehrerer Teile, unabhängig von der Reihenfolge, in der die entsprechende Bereichsspezifikation im empfangenen Range-Headerfeld erschien. Da der typische Overhead zwischen jedem Teil eines "multipart/byteranges" etwa 80 Bytes beträgt, abhängig vom Medientyp der ausgewählten Darstellung und der gewählten Boundary-Parameterlänge, kann es weniger effizient sein, viele kleine disjunkte Teile zu übertragen, als die gesamte ausgewählte Darstellung zu übertragen.

Ein Server DARF KEINE mehrteilige Antwort auf eine Anfrage für einen einzelnen Bereich generieren, da ein Client, der nicht mehrere Teile anfordert, möglicherweise keine mehrteiligen Antworten unterstützt. Ein Server DARF jedoch eine "multipart/byteranges"-Antwort mit nur einem einzigen Body-Teil generieren, wenn mehrere Bereiche angefordert wurden und nur ein Bereich als erfüllbar befunden wurde oder nur ein Bereich nach dem Zusammenführen übrig blieb. Ein Client, der eine "multipart/byteranges"-Antwort nicht verarbeiten kann, DARF KEINE Anfrage generieren, die mehrere Bereiche anfordert.

Ein Server, der eine mehrteilige Antwort generiert, SOLLTE die Teile in derselben Reihenfolge senden, in der die entsprechende Bereichsspezifikation im empfangenen Range-Headerfeld erschien, mit Ausnahme der Bereiche, die als nicht erfüllbar eingestuft oder in andere Bereiche zusammengeführt wurden. Ein Client, der eine mehrteilige Antwort erhält, MUSS das in jedem Body-Teil vorhandene Content-Range-Headerfeld überprüfen, um zu bestimmen, welcher Bereich in diesem Body-Teil enthalten ist; ein Client kann sich nicht darauf verlassen, dieselben Bereiche zu erhalten, die er angefordert hat, noch dieselbe Reihenfolge, die er angefordert hat.

15.3.7.3. Combining Parts

Eine Antwort überträgt möglicherweise nur einen Teilbereich einer Darstellung, wenn die Verbindung vorzeitig geschlossen wurde oder wenn die Anfrage eine oder mehrere Bereichsspezifikationen verwendete. Nach mehreren solchen Übertragungen hat ein Client möglicherweise mehrere Bereiche derselben Darstellung erhalten. Diese Bereiche können nur sicher kombiniert werden, wenn sie alle denselben starken Validator gemeinsam haben (Abschnitt 8.8.1).

Ein Client, der mehrere Teilantworten auf GET-Anfragen an eine Zielressource erhalten hat, DARF diese Antworten zu einem größeren kontinuierlichen Bereich kombinieren, wenn sie denselben starken Validator teilen.

Wenn die neueste Antwort eine unvollständige 200 (OK) Antwort ist, werden die Headerfelder dieser Antwort für jede kombinierte Antwort verwendet und ersetzen die der übereinstimmenden gespeicherten Antworten.

Wenn die neueste Antwort eine 206 (Partial Content) Antwort ist und mindestens eine der übereinstimmenden gespeicherten Antworten eine 200 (OK) ist, bestehen die kombinierten Antwort-Headerfelder aus den Headerfeldern der neuesten 200-Antwort. Wenn alle übereinstimmenden gespeicherten Antworten 206-Antworten sind, wird die gespeicherte Antwort mit den neuesten Headerfeldern als Quelle der Headerfelder für die kombinierte Antwort verwendet, außer dass der Client andere in der neuen Antwort bereitgestellte Headerfelder, abgesehen von Content-Range, verwenden MUSS, um alle Instanzen des entsprechenden Headerfelds in der gespeicherten Antwort zu ersetzen.

Der kombinierte Antwortinhalt besteht aus der Vereinigung der Teilinhaltsbereiche innerhalb der neuen Antwort und aller übereinstimmenden gespeicherten Antworten. Wenn die Vereinigung aus dem gesamten Bereich der Darstellung besteht, MUSS der Client die kombinierte Antwort so verarbeiten, als wäre es eine vollständige 200 (OK) Antwort, einschließlich eines Content-Length-Headerfelds, das die vollständige Länge widerspiegelt. Andernfalls MUSS der Client die Menge der kontinuierlichen Bereiche als eines der folgenden verarbeiten: eine unvollständige 200 (OK) Antwort, wenn die kombinierte Antwort ein Präfix der Darstellung ist, eine einzelne 206 (Partial Content) Antwort, die "multipart/byteranges"-Inhalt enthält, oder mehrere 206 (Partial Content) Antworten, jede mit einem kontinuierlichen Bereich, der durch ein Content-Range-Headerfeld angezeigt wird.

15.4. Redirection 3xx

Die 3xx (Redirection) Klasse von Statuscodes zeigt an, dass weitere Maßnahmen vom User-Agent ergriffen werden müssen, um die Anfrage zu erfüllen. Es gibt mehrere Arten von Weiterleitungen:

Weiterleitungen, die anzeigen, dass diese Ressource möglicherweise unter einer anderen URI verfügbar ist, wie durch das Location-Headerfeld bereitgestellt, wie bei den Statuscodes 301 (Moved Permanently), 302 (Found), 307 (Temporary Redirect) und 308 (Permanent Redirect).
Weiterleitung, die eine Auswahl zwischen übereinstimmenden Ressourcen bietet, die diese Ressource darstellen können, wie beim 300 (Multiple Choices) Statuscode.
Weiterleitung zu einer anderen Ressource, identifiziert durch das Location-Headerfeld, die eine indirekte Antwort auf die Anfrage darstellen kann, wie beim 303 (See Other) Statuscode.
Weiterleitung zu einem zuvor gespeicherten Ergebnis, wie beim 304 (Not Modified) Statuscode.

| Hinweis: In HTTP/1.0 wurden die Statuscodes 301 (Moved Permanently) | und 302 (Found) ursprünglich als methodenerhaltend definiert | ([HTTP/1.0], Abschnitt 9.3), um ihrer Implementierung am CERN zu | entsprechen; 303 (See Other) wurde für eine Weiterleitung definiert, | die ihre Methode in GET änderte. Frühe User-Agents waren jedoch | geteilter Meinung darüber, ob POST-Anfragen als POST (gemäß der | damaligen Spezifikation) oder als GET (die sicherere Alternative bei | Weiterleitung zu einer anderen Site) weitergeleitet werden sollten. | Die vorherrschende Praxis konvergierte schließlich zur Änderung der | Methode in GET. 307 (Temporary Redirect) und 308 (Permanent Redirect) | [RFC7538] wurden später hinzugefügt, um eindeutig methodenerhaltende | Weiterleitungen anzuzeigen, und die Statuscodes 301 und 302 wurden | angepasst, um zuzulassen, dass eine POST-Anfrage als GET weitergeleitet | wird.

Wenn ein Location-Headerfeld (Abschnitt 10.2.2) bereitgestellt wird, DARF der User-Agent seine Anfrage automatisch zu der vom Location-Feldwert referenzierten URI weiterleiten, auch wenn der spezifische Statuscode nicht verstanden wird. Automatische Weiterleitung muss bei Methoden, die nicht als sicher bekannt sind, wie in Abschnitt 9.2.1 definiert, mit Vorsicht durchgeführt werden, da der Benutzer möglicherweise keine unsichere Anfrage weiterleiten möchte.

Beim automatischen Folgen einer weitergeleiteten Anfrage SOLLTE der User-Agent die ursprüngliche Anfragenachricht mit den folgenden Änderungen erneut senden:

Ersetzen Sie die Ziel-URI durch die vom Location-Headerfeld der Weiterleitungsantwort referenzierte URI, nachdem Sie sie relativ zur Ziel-URI der ursprünglichen Anfrage aufgelöst haben.
Entfernen Sie Headerfelder, die automatisch von der Implementierung generiert wurden, und ersetzen Sie sie durch aktualisierte Werte, die für die neue Anfrage geeignet sind. Dies umfasst:
1. Verbindungsspezifische Headerfelder (siehe Abschnitt 7.6.1),
2. Proxy-konfigurationsspezifische Headerfelder, einschließlich (aber nicht beschränkt auf) Proxy-Authorization,
3. Ursprungsspezifische Headerfelder (falls vorhanden), einschließlich (aber nicht beschränkt auf) Host,
4. Validierungsheaderfelder, die vom Cache der Implementierung hinzugefügt wurden (z.B. If-None-Match, If-Modified-Since), und
5. Ressourcenspezifische Headerfelder, einschließlich (aber nicht beschränkt auf) Referer, Origin, Authorization und Cookie.
Erwägen Sie das Entfernen von Headerfeldern, die nicht automatisch von der Implementierung generiert wurden (d.h. diejenigen, die in der Anfrage vorhanden sind, weil sie vom aufrufenden Kontext hinzugefügt wurden), wenn Sicherheitsimplikationen bestehen; dies umfasst unter anderem Authorization und Cookie.
Ändern Sie die Anfragemethode gemäß der Semantik des Weiterleitungsstatuscodes, falls zutreffend.
Wenn die Anfragemethode in GET oder HEAD geändert wurde, entfernen Sie inhaltsspezifische Headerfelder, einschließlich (aber nicht beschränkt auf) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, Last-Modified.

Ein Client SOLLTE zyklische Weiterleitungen erkennen und eingreifen (d.h. "unendliche" Weiterleitungsschleifen).

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

15.4.1. 300 Multiple Choices

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 zu einem oder mehreren dieser Bezeichner weiterleitet. Mit anderen Worten, der Server wünscht, dass der User-Agent reaktive Verhandlung durchführt, um die am besten geeignete Darstellung(en) für seine Bedürfnisse auszuwählen (Abschnitt 12).

Wenn der Server eine bevorzugte Wahl hat, SOLLTE der Server ein Location-Headerfeld generieren, das eine URI-Referenz der bevorzugten Wahl enthält. Der User-Agent DARF den Location-Feldwert für automatische Weiterleitung verwenden.

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

Eine 300-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

| Hinweis: Der ursprüngliche Vorschlag für den 300-Statuscode | definierte das URI-Headerfeld als Bereitstellung einer Liste | alternativer Darstellungen, sodass es für 200-, 300- und 406-Antworten | verwendbar wäre und in Antworten auf die HEAD-Methode übertragen würde. | Mangelnde Bereitstellung und Meinungsverschiedenheiten über die Syntax | führten jedoch dazu, dass sowohl URI als auch Alternates (ein | nachfolgender Vorschlag) aus dieser Spezifikation gestrichen wurden. | Es ist möglich, die Liste als Link-Headerfeld-Wert [RFC8288] zu | kommunizieren, dessen Mitglieder eine Beziehung von "alternate" haben, | obwohl die Bereitstellung ein Henne-Ei-Problem ist.

15.4.2. 301 Moved Permanently

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 beigefügten URIs verwenden sollten. Der Server schlägt vor, dass ein User-Agent mit Link-Editing-Fähigkeit Verweise auf die Ziel-URI dauerhaft durch eine der neuen, vom Server gesendeten Referenzen ersetzen kann. Dieser Vorschlag wird jedoch normalerweise ignoriert, es sei denn, der User-Agent bearbeitet aktiv Verweise (z.B. ist mit der Erstellung von Inhalten beschäftigt), die Verbindung ist gesichert, und der Ursprungsserver ist eine vertrauenswürdige Autorität für den bearbeiteten Inhalt.

Der Server SOLLTE ein Location-Headerfeld in der Antwort generieren, das eine bevorzugte URI-Referenz für die neue permanente URI enthält. Der User-Agent DARF den Location-Feldwert für automatische Weiterleitung verwenden. Der Antwortinhalt des Servers enthält normalerweise eine kurze Hypertext-Notiz mit einem Hyperlink zur neuen URI.

| Hinweis: Aus historischen Gründen DARF ein User-Agent die | Anfragemethode von POST zu GET für die nachfolgende Anfrage ändern. | Wenn dieses Verhalten unerwünscht ist, kann stattdessen der | 308 (Permanent Redirect) Statuscode verwendet werden.

Eine 301-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.4.3. 302 Found

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

Der Server SOLLTE ein Location-Headerfeld in der Antwort generieren, das eine URI-Referenz für die andere URI enthält. Der User-Agent DARF den Location-Feldwert für automatische Weiterleitung verwenden. Der Antwortinhalt des Servers enthält normalerweise eine kurze Hypertext-Notiz mit einem Hyperlink zur anderen URI.

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

15.4.4. 303 See Other

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

Dieser Statuscode ist auf jede HTTP-Methode anwendbar. Er wird hauptsächlich verwendet, um es der Ausgabe einer POST-Aktion zu ermöglichen, den User-Agent zu einer anderen Ressource weiterzuleiten, da dies die der POST-Antwort entsprechenden Informationen als Ressource bereitstellt, die separat identifiziert, mit Lesezeichen versehen und zwischengespeichert werden kann.

Eine 303-Antwort auf eine GET-Anfrage zeigt an, dass der Ursprungsserver keine Darstellung der Zielressource hat, die vom Server über HTTP übertragen werden kann. Das Location-Feldwert verweist jedoch auf eine Ressource, die die Zielressource beschreibt, sodass das Durchführen einer Abrufanfrage an diese andere Ressource zu einer Darstellung führen kann, 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 Geltungsbereichs von HTTP liegen.

Außer bei Antworten auf eine HEAD-Anfrage sollte die Darstellung einer 303-Antwort eine kurze Hypertext-Notiz mit einem Hyperlink zur gleichen URI-Referenz enthalten, die im Location-Headerfeld bereitgestellt wird.

15.4.5. 304 Not Modified

Der 304 (Not Modified) Statuscode zeigt an, dass eine bedingte GET- oder HEAD-Anfrage empfangen wurde und zu einer 200 (OK) Antwort geführt hätte, wenn nicht die Bedingung als falsch bewertet worden wäre. Mit anderen Worten, es besteht keine Notwendigkeit für den Server, eine Darstellung der Zielressource zu übertragen, da die Anfrage anzeigt, dass der Client, der die Anfrage bedingt gemacht hat, bereits über eine gültige Darstellung verfügt; der Server leitet den Client daher um, diese gespeicherte Darstellung so zu verwenden, als wäre sie der Inhalt einer 200 (OK) Antwort.

Der Server, der eine 304-Antwort generiert, MUSS eines der folgenden Headerfelder generieren, das in einer 200 (OK) Antwort auf dieselbe Anfrage gesendet worden wäre:

Content-Location, Date, ETag und Vary
Cache-Control und Expires (siehe [CACHING])

Da das Ziel einer 304-Antwort darin besteht, die Informationsübertragung zu minimieren, wenn der Empfänger bereits eine oder mehrere zwischengespeicherte Darstellungen hat, SOLLTE ein Sender KEINE Darstellungsmetadaten außer den oben aufgeführten Feldern generieren, es sei denn, diese Metadaten existieren zum Zweck der Anleitung von Cache-Aktualisierungen (z.B. könnte Last-Modified nützlich sein, wenn die Antwort kein ETag-Feld hat).

Anforderungen an einen Cache, der eine 304-Antwort erhält, sind in Abschnitt 4.3.4 von [CACHING] definiert. Wenn die bedingte Anfrage von einem ausgehenden Client stammte, wie einem User-Agent mit eigenem Cache, der eine bedingte GET an einen gemeinsam genutzten Proxy sendet, SOLLTE der Proxy die 304-Antwort an diesen Client weiterleiten.

Eine 304-Antwort wird durch das Ende des Header-Bereichs beendet; sie kann keinen Inhalt oder Trailer enthalten.

15.4.6. 305 Use Proxy

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

15.4.7. 306 (Unused)

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

15.4.8. 307 Temporary Redirect

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

15.4.9. 308 Permanent Redirect

Der 308 (Permanent Redirect) Statuscode zeigt an, dass der Zielressource eine neue permanente URI zugewiesen wurde und alle zukünftigen Verweise auf diese Ressource eine der beigefügten URIs verwenden sollten. Der Server schlägt vor, dass ein User-Agent mit Link-Editing-Fähigkeit Verweise auf die Ziel-URI dauerhaft durch eine der neuen, vom Server gesendeten Referenzen ersetzen kann. Dieser Vorschlag wird jedoch normalerweise ignoriert, es sei denn, der User-Agent bearbeitet aktiv Verweise (z.B. ist mit der Erstellung von Inhalten beschäftigt), die Verbindung ist gesichert, und der Ursprungsserver ist eine vertrauenswürdige Autorität für den bearbeiteten Inhalt.

Eine 308-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

| Hinweis: Dieser Statuscode ist viel jünger (Juni 2014) als seine | Geschwistercodes und wird daher möglicherweise nicht überall erkannt. | Siehe Abschnitt 4 von [RFC7538] für Bereitstellungsüberlegungen.

15.5. Client Error 4xx

Die 4xx (Client Error) Klasse von Statuscodes zeigt an, dass der Client offenbar einen Fehler gemacht hat. 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 einen vorübergehenden oder dauerhaften Zustand handelt. Diese Statuscodes gelten für jede Anfragemethode. User-Agents SOLLTEN jede enthaltene Darstellung dem Benutzer anzeigen.

15.5.1. 400 Bad Request

Der 400 (Bad Request) Statuscode zeigt an, dass der Server die Anfrage aufgrund von etwas, das als Clientfehler wahrgenommen wird (z.B. fehlerhafte Anfragsyntax, ungültige Anfragenachrichten-Rahmung oder täuschende Anfrageweiterleitung), nicht oder nicht verarbeiten wird.

15.5.2. 401 Unauthorized

Der 401 (Unauthorized) Statuscode zeigt an, dass die Anfrage nicht angewendet wurde, da gültige Authentifizierungsnachweise für die Zielressource fehlen. Der Server, der eine 401-Antwort generiert, MUSS ein WWW-Authenticate-Headerfeld (Abschnitt 11.6.1) senden, das mindestens eine auf die Zielressource anwendbare Herausforderung enthält.

Wenn die Anfrage Authentifizierungsnachweise enthielt, zeigt die 401-Antwort an, dass die Autorisierung für diese Nachweise abgelehnt wurde. Der User-Agent DARF die Anfrage mit einem neuen oder ersetzten Authorization-Headerfeld (Abschnitt 11.6.2) wiederholen. Wenn die 401-Antwort dieselbe Herausforderung wie die vorherige Antwort enthält und der User-Agent bereits mindestens einmal eine Authentifizierung versucht hat, SOLLTE der User-Agent die beigefügte Darstellung dem Benutzer präsentieren, da sie normalerweise relevante Diagnoseinformationen enthält.

15.5.3. 402 Payment Required

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

15.5.4. 403 Forbidden

Der 403 (Forbidden) Statuscode zeigt an, dass der Server die Anfrage verstanden hat, sich aber weigert, sie zu erfüllen. Ein Server, der öffentlich machen möchte, warum die Anfrage verboten wurde, kann diesen Grund im Antwortinhalt beschreiben (falls vorhanden).

Wenn in der Anfrage Authentifizierungsnachweise bereitgestellt wurden, betrachtet der Server diese als unzureichend, um Zugriff zu gewähren. Der Client SOLLTE die Anfrage NICHT automatisch mit denselben Nachweisen wiederholen. Der Client DARF die Anfrage mit neuen oder anderen Nachweisen wiederholen. Eine Anfrage kann jedoch aus Gründen verboten sein, die nichts mit den Nachweisen zu tun haben.

Ein Ursprungsserver, der die aktuelle Existenz einer verbotenen Zielressource "verstecken" möchte, DARF stattdessen mit einem Statuscode 404 (Not Found) antworten.

15.5.5. 404 Not Found

Der 404 (Not Found) Statuscode zeigt an, dass der Ursprungsserver keine aktuelle Darstellung für die Zielressource gefunden hat oder nicht bereit ist offenzulegen, dass eine existiert. Ein 404-Statuscode zeigt nicht an, ob dieses Fehlen der Darstellung vorübergehend oder dauerhaft ist; der 410 (Gone) Statuscode wird gegenüber 404 bevorzugt, wenn der Ursprungsserver, vermutlich durch eine konfigurierbare Einrichtung, weiß, dass der Zustand wahrscheinlich dauerhaft ist.

Eine 404-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.5.6. 405 Method Not Allowed

Der 405 (Method Not Allowed) Statuscode zeigt an, dass die in der Anfragezeile empfangene Methode vom Ursprungsserver bekannt ist, aber von der Zielressource nicht unterstützt wird. Der Ursprungsserver MUSS ein Allow-Headerfeld in einer 405-Antwort generieren, das eine Liste der derzeit von der Zielressource unterstützten Methoden enthält.

Eine 405-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.5.7. 406 Not Acceptable

Der 406 (Not Acceptable) Statuscode zeigt an, dass die Zielressource keine aktuelle Darstellung hat, die für den User-Agent gemäß den proaktiven Verhandlungsheaderfeldern, die in der Anfrage empfangen wurden (Abschnitt 12.1), akzeptabel wäre, und der Server nicht bereit ist, eine Standarddarstellung bereitzustellen.

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

15.5.8. 407 Proxy Authentication Required

Der 407 (Proxy Authentication Required) Statuscode ist ähnlich wie 401 (Unauthorized), zeigt jedoch an, dass der Client sich selbst authentifizieren muss, um einen Proxy für diese Anfrage zu verwenden. Der Proxy MUSS ein Proxy-Authenticate-Headerfeld (Abschnitt 11.7.1) senden, das eine auf diesen Proxy für die Anfrage anwendbare Herausforderung enthält. Der Client DARF die Anfrage mit einem neuen oder ersetzten Proxy-Authorization-Headerfeld (Abschnitt 11.7.2) wiederholen.

15.5.9. 408 Request 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.

Wenn der Client eine ausstehende Anfrage unterwegs hat, DARF er diese Anfrage wiederholen. Wenn die aktuelle Verbindung nicht verwendbar ist (z.B. wie in HTTP/1.1, weil die Anfragedelimitierung verloren geht), wird eine neue Verbindung verwendet.

15.5.10. 409 Conflict

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 übermitteln. Der Server SOLLTE Inhalt generieren, der 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 denen einer früheren (Drittpartei-) Anfrage in Konflikt stehen, könnte der Ursprungsserver eine 409-Antwort verwenden, um anzuzeigen, dass er die Anfrage nicht abschließen kann. In diesem Fall würde die Antwortdarstellung wahrscheinlich Informationen enthalten, die für das Zusammenführen der Unterschiede basierend auf der Revisionsgeschichte nützlich sind.

15.5.11. 410 Gone

Der 410 (Gone) Statuscode zeigt an, dass der Zugriff auf die Zielressource auf dem Ursprungsserver nicht mehr verfügbar ist und dieser Zustand wahrscheinlich dauerhaft ist. Wenn der Ursprungsserver nicht weiß oder keine Möglichkeit hat festzustellen, ob der Zustand dauerhaft ist, sollte stattdessen der Statuscode 404 (Not Found) verwendet werden.

Die 410-Antwort ist hauptsächlich dazu gedacht, die Aufgabe der Web-Wartung zu unterstützen, indem sie den Empfänger benachrichtigt, dass die Ressource absichtlich nicht verfügbar ist und die Server-Eigentümer wünschen, dass entfernte Links zu dieser Ressource entfernt werden. Ein solches Ereignis ist häufig bei zeitlich begrenzten Werbediensten und für Ressourcen, die Personen gehören, die nicht mehr mit der Site des Ursprungsservers verbunden sind. Es ist nicht erforderlich, alle dauerhaft nicht verfügbaren Ressourcen als "gone" zu markieren oder die Markierung für eine bestimmte Zeit aufrechtzuerhalten -- das bleibt dem Ermessen des Server-Eigentümers überlassen.

Eine 410-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.5.12. 411 Length Required

Der 411 (Length Required) Statuscode zeigt an, dass der Server sich weigert, die Anfrage ohne definierte Content-Length (Abschnitt 8.6) zu akzeptieren. Der Client DARF die Anfrage wiederholen, wenn er ein gültiges Content-Length-Headerfeld hinzufügt, das die Länge des Anfrageinhalts enthält.

15.5.13. 412 Precondition Failed

Der 412 (Precondition Failed) Statuscode zeigt an, dass eine oder mehrere in den Anfrage-Headerfeldern angegebene Bedingungen beim Testen auf dem Server als falsch bewertet wurden (Abschnitt 13). Dieser Antwortstatuscode ermöglicht es dem Client, Vorbedingungen für den aktuellen Ressourcenzustand (seine aktuellen Darstellungen und Metadaten) festzulegen und somit zu verhindern, dass die Anfragemethode angewendet wird, wenn die Zielressource in einem unerwarteten Zustand ist.

15.5.14. 413 Content Too Large

Der 413 (Content Too Large) Statuscode zeigt an, dass der Server sich weigert, eine Anfrage zu verarbeiten, da der Anfrageinhalt größer ist, als der Server bereit oder in der Lage ist zu verarbeiten. Der Server DARF die Anfrage beenden, wenn die verwendete Protokollversion dies zulässt; andernfalls DARF der Server die Verbindung schließen.

Wenn der Zustand vorübergehend ist, SOLLTE der Server ein Retry-After-Headerfeld generieren, um anzuzeigen, dass er vorübergehend ist und nach welcher Zeit der Client es erneut versuchen DARF.

15.5.15. 414 URI Too Long

Der 414 (URI Too Long) Statuscode zeigt an, dass der Server sich weigert, die Anfrage zu bedienen, da die Ziel-URI länger ist, als der Server bereit ist zu interpretieren. Dieser seltene Zustand tritt wahrscheinlich nur auf, wenn ein Client eine POST-Anfrage unsachgemäß in eine GET-Anfrage mit langen Abfrageinformationen umgewandelt hat, wenn der Client in eine Endlosschleife der Weiterleitung geraten ist (z.B. ein weitergeleitetes URI-Präfix, das auf ein Suffix von sich selbst verweist) oder wenn der Server von einem Client angegriffen wird, der versucht, potenzielle Sicherheitslücken auszunutzen.

Eine 414-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.5.16. 415 Unsupported Media Type

Der 415 (Unsupported Media Type) Statuscode zeigt an, dass der Ursprungsserver sich weigert, die Anfrage zu bedienen, da der Inhalt in einem Format vorliegt, das von dieser Methode auf der Zielressource nicht unterstützt wird.

Das Formatproblem könnte auf den angegebenen Content-Type oder Content-Encoding der Anfrage oder als Ergebnis einer direkten Inspektion der Daten zurückzuführen sein.

Wenn das Problem durch eine nicht unterstützte Inhaltscodierung verursacht wurde, sollte das Accept-Encoding-Antwort-Headerfeld (Abschnitt 12.5.3) verwendet werden, um anzugeben, welche (falls vorhanden) Inhaltscodierungen in der Anfrage akzeptiert worden wären.

Andererseits, wenn die Ursache ein nicht unterstützter Medientyp war, kann das Accept-Antwort-Headerfeld (Abschnitt 12.5.1) verwendet werden, um anzugeben, welche Medientypen in der Anfrage akzeptiert worden wären.

15.5.17. 416 Range Not Satisfiable

Der 416 (Range Not Satisfiable) Statuscode zeigt an, dass die Menge der Bereiche im Range-Headerfeld der Anfrage (Abschnitt 14.2) abgelehnt wurde, entweder weil keiner der angeforderten Bereiche erfüllbar ist oder weil der Client eine übermäßige Anzahl kleiner oder sich überschneidender Bereiche angefordert hat (ein potenzieller Denial-of-Service-Angriff).

Jede Bereichseinheit definiert, was für ihre eigenen Bereichsmengen erforderlich ist, um erfüllbar zu sein. Beispielsweise definiert Abschnitt 14.1.2, was eine Bytes-Bereichsmenge erfüllbar macht.

Ein Server, der eine 416-Antwort auf eine Byte-Bereichsanfrage generiert, SOLLTE ein Content-Range-Headerfeld generieren, das die aktuelle Länge der ausgewählten Darstellung angibt (Abschnitt 14.4).

Beispiel:

HTTP/1.1 416 Range Not Satisfiable Date: Fri, 20 Jan 2012 15:41:54 GMT Content-Range: bytes */47022

| Hinweis: Da Server frei sind, Range zu ignorieren, werden viele | Implementierungen mit der gesamten ausgewählten Darstellung in einer | 200 (OK) Antwort antworten. Das liegt teilweise daran, dass die | meisten Clients darauf vorbereitet sind, eine 200 (OK) zu empfangen, | um die Aufgabe abzuschließen (wenn auch weniger effizient), und | teilweise daran, dass Clients möglicherweise nicht aufhören, eine | ungültige Bereichsanfrage zu stellen, bis sie eine vollständige | Darstellung erhalten haben. Daher können sich Clients nicht darauf | verlassen, eine 416 (Range Not Satisfiable) Antwort zu erhalten, | selbst wenn sie am angemessensten wäre.

15.5.18. 417 Expectation Failed

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

15.5.19. 418 (Unused)

[RFC2324] war ein RFC vom 1. April, der die verschiedenen Arten verspottete, wie HTTP missbraucht wurde; ein solcher Missbrauch war die Definition eines anwendungsspezifischen 418-Statuscodes, der oft genug als Scherz eingesetzt wurde, dass der Code für eine zukünftige Verwendung nicht verwendbar ist.

Daher ist der 418-Statuscode in der IANA HTTP-Statuscode-Registry reserviert. Dies zeigt an, dass der Statuscode derzeit keinen anderen Anwendungen zugewiesen werden kann. Wenn zukünftige Umstände seine Verwendung erfordern (z.B. Erschöpfung der 4NN-Statuscodes), kann er einer anderen Verwendung neu zugewiesen werden.

15.5.20. 421 Misdirected Request

Der 421 (Misdirected Request) Statuscode zeigt an, dass die Anfrage an einen Server gerichtet wurde, der nicht in der Lage oder nicht bereit ist, eine autoritative Antwort für die Ziel-URI zu erzeugen. Ein Ursprungsserver (oder Gateway, das im Namen des Ursprungsservers handelt) sendet 421, um eine Ziel-URI abzulehnen, die nicht mit einem Ursprung übereinstimmt, für den der Server konfiguriert wurde (Abschnitt 4.3.1), oder die nicht mit dem Verbindungskontext übereinstimmt, über den die Anfrage empfangen wurde (Abschnitt 7.4).

Ein Client, der eine 421 (Misdirected Request) Antwort erhält, DARF die Anfrage wiederholen, unabhängig davon, ob die Anfragemethode idempotent ist oder nicht, über eine andere Verbindung, wie eine neue Verbindung, die speziell für den Ursprung der Zielressource ist, oder über einen alternativen Dienst [ALTSVC].

Ein Proxy DARF KEINE 421-Antwort generieren.

15.5.21. 422 Unprocessable Content

Der 422 (Unprocessable Content) Statuscode zeigt an, dass der Server den Inhaltstyp des Anfrageinhalts versteht (daher ist ein 415 (Unsupported Media Type) Statuscode unpassend) und die Syntax des Anfrageinhalts korrekt ist, er jedoch nicht in der Lage war, die enthaltenen Anweisungen zu verarbeiten. Beispielsweise kann dieser Statuscode gesendet werden, wenn ein XML-Anfraginhalt wohlgeformte (d.h. syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

15.5.22. 426 Upgrade Required

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-Headerfeld in einer 426-Antwort senden, um das/die erforderliche(n) Protokoll(e) anzuzeigen (Abschnitt 7.8).

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.

15.6. Server Error 5xx

Die 5xx (Server Error) Klasse von Statuscodes zeigt an, dass der Server weiß, 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 einen vorübergehenden oder dauerhaften Zustand handelt. Ein User-Agent SOLLTE jede enthaltene Darstellung dem Benutzer anzeigen. Diese Statuscodes gelten für jede Anfragemethode.

15.6.1. 500 Internal Server Error

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

15.6.2. 501 Not Implemented

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

Eine 501-Antwort ist heuristisch cachebar; d.h., sofern nicht anders durch die Methodendefinition oder explizite Cache-Steuerungen angegeben (siehe Abschnitt 4.2.2 von [CACHING]).

15.6.3. 502 Bad 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 erhielt, auf den er beim Versuch, die Anfrage zu erfüllen, zugegriffen hat.

15.6.4. 503 Service Unavailable

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 einer gewissen Verzögerung behoben wird. Der Server DARF ein Retry-After-Headerfeld (Abschnitt 10.2.3) senden, um einen angemessenen Zeitraum vorzuschlagen, den der Client warten sollte, bevor er die Anfrage wiederholt.

| Hinweis: Die Existenz des 503-Statuscodes impliziert nicht, dass ein | Server ihn verwenden muss, wenn er überlastet wird. Einige Server | lehnen möglicherweise einfach die Verbindung ab.

15.6.5. 504 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 erhielt, auf den er zugreifen musste, um die Anfrage abzuschließen.

15.6.6. 505 HTTP Version Not Supported

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, sie 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 Abschnitt 2.5 beschrieben, außer mit dieser Fehlermeldung. Der Server SOLLTE eine Darstellung für die 505-Antwort generieren, die beschreibt, warum diese Version nicht unterstützt wird und welche anderen Protokolle von diesem Server unterstützt werden.