10. Status Code Definitions (Statuscode-Definitionen)
Im Folgenden wird jeder Statuscode beschrieben, einschließlich einer Beschreibung, welchen Methoden er folgen kann, und aller in der Antwort erforderlichen Metainformationen.
10.1 Informational 1xx (Informativ)
Diese Klasse von Statuscodes zeigt eine vorläufige Antwort an, die nur aus der Status-Line und optionalen Headern besteht und durch eine Leerzeile abgeschlossen wird. Es gibt keine erforderlichen Header für diese Klasse von Statuscodes. Da HTTP/1.0 keine 1xx-Statuscodes definiert hat, dürfen (MUST NOT) Server keine 1xx-Antwort an einen HTTP/1.0-Client senden, außer unter experimentellen Bedingungen.
Ein Client muss (MUST) darauf vorbereitet sein, vor der regulären Antwort eine oder mehrere 1xx-Statusantworten zu akzeptieren, auch wenn der Client keine 100 (Continue)-Statusnachricht erwartet. Benutzeragenten können (MAY) unerwartete 1xx-Statusantworten ignorieren.
Ein Proxy muss (MUST) 1xx-Antworten weiterleiten, es sei denn, die Verbindung zwischen dem Proxy und seinem Client wurde geschlossen, oder es sei denn, der Proxy selbst hat die Generierung der 1xx-Antwort angefordert. (Zum Beispiel, wenn ein Proxy beim Weiterleiten einer Anfrage ein "Expect: 100-continue"-Feld hinzufügt, muss er die entsprechende 100 (Continue)-Antwort nicht weiterleiten.)
10.1.1 100 Continue
Der Client sollte (SHOULD) mit seiner Anfrage fortfahren. Diese vorläufige Antwort wird verwendet, um dem Client mitzuteilen, dass der anfängliche Teil der Anfrage empfangen wurde und noch nicht vom Server abgelehnt wurde. Der Client sollte (SHOULD) mit dem Senden des Rests der Anfrage fortfahren oder, wenn die Anfrage bereits abgeschlossen ist, diese Antwort ignorieren. Der Server muss (MUST) eine endgültige Antwort senden, nachdem die Anfrage abgeschlossen ist. Siehe Abschnitt 8.2.3 für eine ausführliche Diskussion über die Verwendung und Handhabung dieses Statuscodes.
10.1.2 101 Switching Protocols (Protokollwechsel)
Der Server versteht die Anfrage des Clients über das Upgrade-Nachrichtenheaderfeld (Abschnitt 14.42) und willigt ein, das auf dieser Verbindung verwendete Anwendungsprotokoll zu ändern. Der Server wird unmittelbar nach der Leerzeile, die die 101-Antwort beendet, zu den in dem Upgrade-Headerfeld der Antwort definierten Protokollen wechseln.
Das Protokoll sollte (SHOULD) nur gewechselt werden, wenn es vorteilhaft ist. Zum Beispiel ist der Wechsel zu einer neueren Version von HTTP gegenüber älteren Versionen vorteilhaft, und der Wechsel zu einem Echtzeit-, synchronen Protokoll könnte bei der Bereitstellung von Ressourcen, die solche Funktionen verwenden, vorteilhaft sein.
10.2 Successful 2xx (Erfolg)
Diese Klasse von Statuscodes zeigt an, dass die Anfrage des Clients erfolgreich empfangen, verstanden und akzeptiert wurde.
10.2.1 200 OK
Die Anfrage war erfolgreich. Die mit der Antwort zurückgegebenen Informationen hängen von der in der Anfrage verwendeten Methode ab, zum Beispiel:
- GET - eine Entität, die der angeforderten Ressource entspricht, wird in der Antwort gesendet;
- HEAD - die Entitätsheaderfelder, die der angeforderten Ressource entsprechen, werden ohne Nachrichtenkörper in der Antwort gesendet;
- POST - eine Entität, die das Ergebnis der Aktion beschreibt oder enthält;
- TRACE - eine Entität, die die vom Endserver empfangene Anfragenachricht enthält.
10.2.2 201 Created (Erstellt)
Die Anfrage wurde erfüllt und hat zur Erstellung einer neuen Ressource geführt. Die neu erstellte Ressource kann durch die in der Antwortentität zurückgegebenen URIs referenziert werden, wobei der spezifischste URI für die Ressource durch ein Location-Headerfeld angegeben wird. Die Antwort sollte (SHOULD) eine Entität enthalten, die eine Liste der Ressourcenmerkmale und -standorte enthält, aus der der Benutzer oder Benutzeragent das am besten geeignete auswählen kann. Das Entitätsformat wird durch den im Content-Type-Headerfeld angegebenen Medientyp spezifiziert. Der Ursprungsserver muss (MUST) die Ressource erstellen, bevor er den 201-Statuscode zurückgibt. Wenn die Aktion nicht sofort ausgeführt werden kann, sollte (SHOULD) der Server stattdessen mit der 202 (Accepted)-Antwort antworten.
Eine 201-Antwort kann (MAY) ein ETag-Antwort-Headerfeld enthalten, das den aktuellen Wert des Entity-Tags für die gerade erstellte Anfragevariante angibt, siehe Abschnitt 14.19.
10.2.3 202 Accepted (Akzeptiert)
Die Anfrage wurde zur Verarbeitung akzeptiert, aber die Verarbeitung ist noch nicht abgeschlossen. Die Anfrage könnte oder könnte nicht schließlich ausgeführt werden, da sie möglicherweise nicht erlaubt ist, wenn die tatsächliche Verarbeitung stattfindet. Es gibt keine Möglichkeit, einen Statuscode von einer solchen asynchronen Operation erneut zu senden.
Die 202-Antwort ist absichtlich unverbindlich. Ihr Zweck ist es, einem Server zu erlauben, eine Anfrage für einen anderen Prozess zu akzeptieren (vielleicht einen Batch-orientierten Prozess, der nur einmal täglich ausgeführt wird), ohne dass die Verbindung des Benutzeragenten zum Server bestehen bleibt, bis der Prozess abgeschlossen ist. Die mit dieser Antwort zurückgegebene Entität sollte (SHOULD) eine Anzeige des aktuellen Status der Anfrage und entweder einen Zeiger auf einen Statusmonitor oder eine Schätzung enthalten, wann der Benutzer erwarten kann, dass die Anfrage erfüllt wird.
10.2.4 203 Non-Authoritative Information (Nicht-autoritative Information)
Die im Entitätsheader zurückgegebenen Metainformationen stammen nicht aus dem endgültigen Satz des Ursprungsservers, sondern werden aus einer lokalen oder Drittanbieterkopie gesammelt. Der präsentierte Satz kann (MAY) eine Teilmenge oder Obermenge der ursprünglichen Version sein. Zum Beispiel könnte das Einbeziehen lokaler Anmerkungsinformationen über die Ressource zu einer Obermenge der vom Ursprungsserver bekannten Metainformationen führen. Die Verwendung dieses Antwortcodes ist nicht erforderlich und nur dann angemessen, wenn die Antwort andernfalls 200 (OK) wäre.
10.2.5 204 No Content (Kein Inhalt)
Der Server hat die Anfrage erfüllt, muss aber keinen Entitätskörper zurückgeben und möchte möglicherweise aktualisierte Metainformationen zurückgeben. Die Antwort kann (MAY) neue oder aktualisierte Metainformationen in Form von Entitätsheadern enthalten, die, falls vorhanden, mit der angeforderten Variante verknüpft werden sollten (SHOULD).
Wenn der Client ein Benutzeragent ist, sollte (SHOULD NOT) er seine Dokumentenansicht nicht von derjenigen ändern, die das Senden der Anfrage verursacht hat. Diese Antwort ist hauptsächlich dazu gedacht, die Eingabe für die Aktion zu ermöglichen, ohne eine Änderung der aktiven Dokumentenansicht des Benutzeragenten zu verursachen, obwohl alle neuen oder aktualisierten Metainformationen auf das Dokument angewendet werden sollten (SHOULD), das sich derzeit in der aktiven Ansicht des Benutzeragenten befindet.
Die 204-Antwort darf (MUST NOT) einen Nachrichtenkörper enthalten und wird daher immer durch die erste Leerzeile nach den Headerfeldern beendet.
10.2.6 205 Reset Content (Inhalt zurücksetzen)
Der Server hat die Anfrage erfüllt und der Benutzeragent sollte (SHOULD) die Dokumentenansicht zurücksetzen, die das Senden der Anfrage verursacht hat. Diese Antwort ist hauptsächlich dazu gedacht, die Eingabe für Benutzereingabeaktionen zu ermöglichen, gefolgt von einem Löschen des Formulars, in dem die Eingabe gegeben wird, damit der Benutzer problemlos eine weitere Eingabeaktion starten kann. Die Antwort darf (MUST NOT) eine Entität enthalten.
10.2.7 206 Partial Content (Teilinhalt)
Der Server hat die teilweise GET-Anfrage für die Ressource erfüllt. Die Anfrage muss (MUST) ein Range-Headerfeld (Abschnitt 14.35) enthalten haben, das den gewünschten Bereich angibt, und kann (MAY) ein If-Range-Headerfeld (Abschnitt 14.27) enthalten haben, um die Anfrage bedingt zu machen.
Die Antwort muss (MUST) die folgenden Headerfelder enthalten:
-
Entweder ein Content-Range-Headerfeld (Abschnitt 14.16), das den in dieser Antwort enthaltenen Bereich angibt, oder einen multipart/byteranges Content-Type mit Content-Range-Feldern für jeden Teil. Wenn ein Content-Length-Headerfeld in der Antwort vorhanden ist, muss (MUST) sein Wert mit der tatsächlichen Anzahl der im Nachrichtenkörper übertragenen Oktette übereinstimmen.
-
Date
-
ETag und/oder Content-Location, wenn der Header in einer 200-Antwort auf dieselbe Anfrage gesendet worden wäre
-
Expires, Cache-Control und/oder Vary, wenn der Feldwert von dem in einer vorherigen Antwort für dieselbe Variante gesendeten abweichen könnte
Wenn die 206-Antwort das Ergebnis einer bedingten Anfrage ist, die einen starken Cache-Validator verwendet (siehe Abschnitt 13.3.3), sollte (SHOULD NOT) die Antwort keine anderen Entitätsheader enthalten. Dies verhindert Inkonsistenzen zwischen zwischengespeicherten Entitätskörpern und aktualisierten Headern. Andernfalls muss (MUST) die Antwort alle Entitätsheader enthalten, die in einer 200 (OK)-Antwort auf dieselbe Anfrage zurückgegeben worden wären.
Ein Cache darf (MUST NOT) eine 206-Antwort mit anderen zuvor zwischengespeicherten Inhalten kombinieren, wenn das ETag oder die Last-Modified-Header nicht genau mit denen übereinstimmen, die zuvor vom Ursprungsserver empfangen wurden, und muss (MUST) die Teilantwort als vollständig behandeln.
Ein Cache, der die Range- und Content-Range-Header nicht unterstützt, darf (MUST NOT) 206 (Partial)-Antworten zwischenspeichern.
10.3 Redirection 3xx (Umleitung)
Diese Klasse von Statuscodes zeigt an, dass weitere Maßnahmen vom Benutzeragenten ergriffen werden müssen, um die Anfrage zu erfüllen. Die erforderliche Aktion kann (MAY) vom Benutzeragenten ohne Interaktion mit dem Benutzer ausgeführt werden, wenn und nur wenn die in der zweiten Anfrage verwendete Methode GET oder HEAD ist. Ein Client sollte (SHOULD) unendliche Umleitungsschleifen erkennen, da solche Schleifen für jede Umleitung Netzwerkverkehr erzeugen.
Hinweis: Frühere Versionen dieser Spezifikation empfahlen maximal fünf Umleitungen. Inhalteentwickler sollten sich bewusst sein, dass es möglicherweise Clients gibt, die dieser Empfehlung nicht folgen.
10.3.1 300 Multiple Choices (Mehrere Auswahlmöglichkeiten)
Die angeforderte Ressource entspricht einem von mehreren Darstellungen, jede mit ihrem eigenen spezifischen Standort, und agentengesteuerte Verhandlungsinformationen (Abschnitt 12) werden bereitgestellt, damit der Benutzer (oder Benutzeragent) eine bevorzugte Darstellung auswählen und seine Anfrage an diesen Standort umleiten kann.
Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte (SHOULD) die Antwort eine Entität enthalten, die eine Liste der Ressourcenmerkmale und -standorte enthält, aus der der Benutzer oder Benutzeragent das am besten geeignete auswählen kann. Das Entitätsformat wird durch den im Content-Type-Headerfeld angegebenen Medientyp spezifiziert. Abhängig vom Format und den Fähigkeiten des Benutzeragenten kann die Auswahl des am besten geeigneten automatisch vorgenommen werden. Diese Spezifikation definiert jedoch keinen Standard für eine solche automatische Auswahl.
Wenn der Server eine bevorzugte Darstellungsauswahl hat, sollte (SHOULD) er den spezifischen URI für diese Darstellung im Location-Feld angeben; Benutzeragenten können (MAY) den Location-Feldwert für die automatische Umleitung verwenden. Diese Antwort ist cachebar, sofern nicht anders angegeben.
10.3.2 301 Moved Permanently (Dauerhaft verschoben)
Der angeforderten Ressource wurde ein neuer permanenter URI zugewiesen, und alle zukünftigen Verweise auf diese Ressource sollten (SHOULD) einen der zurückgegebenen URIs verwenden. Clients mit Link-Bearbeitungsfähigkeiten sollten (SHOULD) Verweise auf den Request-URI automatisch zu einer oder mehreren der vom Server zurückgegebenen neuen Verweise neu verknüpfen, wenn möglich. Diese Antwort ist cachebar, sofern nicht anders angegeben.
Der neue permanente URI sollte (SHOULD) durch das Location-Feld in der Antwort angegeben werden. Sofern die Anfragemethode nicht HEAD war, sollte (SHOULD) die Entität der Antwort einen kurzen Hyperlink zum neuen URI mit einer kurzen Notiz enthalten.
Wenn der 301-Statuscode als Antwort auf eine andere Anfrage als GET oder HEAD empfangen wird, darf (MUST NOT) der Benutzeragent die Anfrage nicht automatisch umleiten, es sei denn, sie kann vom Benutzer bestätigt werden, da dies die Bedingungen ändern könnte, unter denen die Anfrage ausgegeben wurde.
Hinweis: Beim automatischen Umleiten einer POST-Anfrage ändern einige vorhandene HTTP/1.0-Benutzeragenten diese fälschlicherweise in eine GET-Anfrage.
10.3.3 302 Found
Die angeforderte Ressource befindet sich vorübergehend unter einem anderen URI. Da die Umleitung von Zeit zu Zeit geändert werden könnte, sollte (SHOULD) der Client den Request-URI für zukünftige Anfragen weiterhin verwenden. Diese Antwort ist nur cachebar, wenn sie durch ein Cache-Control- oder Expires-Headerfeld angegeben wird.
Der temporäre URI sollte (SHOULD) durch das Location-Feld in der Antwort angegeben werden. Sofern die Anfragemethode nicht HEAD war, sollte (SHOULD) die Entität der Antwort einen kurzen Hyperlink zum neuen URI mit einer kurzen Notiz enthalten.
Wenn der 302-Statuscode als Antwort auf eine andere Anfrage als GET oder HEAD empfangen wird, darf (MUST NOT) der Benutzeragent die Anfrage nicht automatisch umleiten, es sei denn, sie kann vom Benutzer bestätigt werden, da dies die Bedingungen ändern könnte, unter denen die Anfrage ausgegeben wurde.
Hinweis: RFC 1945 und RFC 2068 spezifizierten, dass der Client die Methode bei der umgeleiteten Anfrage nicht ändern darf. Die meisten vorhandenen Benutzeragenten-Implementierungen behandeln 302 jedoch so, als wäre es eine 303-Antwort, und führen ein GET auf dem Location-Feldwert aus, unabhängig von der ursprünglichen Anfragemethode. Die Statuscodes 303 und 307 wurden für Server hinzugefügt, die klarstellen möchten, welche Reaktion vom Client erwartet wird.
10.3.4 303 See Other (Siehe Andere)
Die Antwort auf die Anfrage kann unter einem anderen URI gefunden werden und sollte (SHOULD) mit einer GET-Methode auf diese Ressource abgerufen werden. Diese Methode existiert hauptsächlich, um die Ausgabe einer POST-aktivierten Aktion zu ermöglichen, den Benutzeragenten zu einer ausgewählten Ressource umzuleiten. Der neue URI ist keine Ersatzreferenz für die ursprünglich angeforderte Ressource. Die 303-Antwort darf (MUST NOT) zwischengespeichert werden, aber die Antwort auf die zweite (umgeleitete) Anfrage könnte cachebar sein.
Der andere URI sollte durch das Location-Feld in der Antwort angegeben werden. Sofern die Anfragemethode nicht HEAD war, sollte (SHOULD) die Entität der Antwort einen kurzen Hyperlink zum neuen URI mit einer kurzen Notiz enthalten.
Hinweis: Viele Pre-HTTP/1.1-Benutzeragenten verstehen den 303-Status nicht. Wenn die Interoperabilität mit solchen Clients ein Problem ist, kann stattdessen der 302-Statuscode verwendet werden, da die meisten Benutzeragenten auf eine 302-Antwort so reagieren, wie es für eine 303-Antwort erforderlich ist.
10.3.5 304 Not Modified (Nicht geändert)
Wenn der Client eine bedingte GET-Anfrage ausgeführt hat und der Zugriff erlaubt ist, das Dokument jedoch nicht geändert wurde, sollte (SHOULD) der Server mit diesem Statuscode antworten. Die 304-Antwort darf (MUST NOT) einen Nachrichtenkörper enthalten und wird daher immer durch die erste Leerzeile nach den Headerfeldern beendet.
Die Antwort muss (MUST) die folgenden Headerfelder enthalten:
- Date, es sei denn, seine Auslassung ist gemäß den Regeln in Abschnitt 14.18.1 erforderlich
Wenn ein Ursprungsserver ohne Uhr diese Regeln befolgt und Proxys und Clients ihre eigenen Date zu allen Date-Headern hinzufügen, die sie empfangen, werden Caches korrekt funktionieren.
- ETag und/oder Content-Location, wenn der Header in einer 200-Antwort auf dieselbe Anfrage gesendet worden wäre
- Expires, Cache-Control und/oder Vary, wenn der Feldwert von dem in einer vorherigen Antwort für dieselbe Variante gesendeten abweichen könnte
Wenn das bedingte GET einen starken Cache-Validator verwendet hat (siehe Abschnitt 13.3.3), sollte (SHOULD NOT) die Antwort keine anderen Entitätsheader enthalten. Andernfalls (d.h. das bedingte GET hat einen schwachen Validator verwendet) darf (MUST NOT) die Antwort keine anderen Entitätsheader enthalten; dies verhindert Inkonsistenzen zwischen zwischengespeicherten Entitätskörpern und aktualisierten Headern.
Wenn eine 304-Antwort eine Entität anzeigt, die derzeit nicht zwischengespeichert ist, muss (MUST) der Cache die Antwort ignorieren und die Anfrage ohne die Bedingung wiederholen.
Wenn ein Cache eine 304-Antwort empfängt, die einen Cache-Eintrag aktualisiert, den er derzeit zwischengespeichert hat, muss (MUST) der Cache den Eintrag aktualisieren, um alle neuen Feldwerte widerzuspiegeln, die in der Antwort angegeben sind.
10.3.6 305 Use Proxy (Proxy verwenden)
Auf die angeforderte Ressource muss (MUST) über den durch das Location-Feld angegebenen Proxy zugegriffen werden. Das Location-Feld gibt den URI des Proxys an. Der Empfänger wird erwartet, diese einzelne Anfrage über den Proxy zu wiederholen. 305-Antworten müssen (MUST) nur von Ursprungsservern generiert werden.
Hinweis: RFC 2068 hat nicht eindeutig angegeben, dass 305 dazu gedacht war, eine einzelne Anfrage an einen Proxy umzuleiten. Das unangemessene Zwischenspeichern von 305-Antworten hat zu erheblichen Sicherheitsproblemen geführt, indem nachfolgende Anfragen an diesen Proxy geleitet wurden.
10.3.7 306 (Unused) (Nicht verwendet)
Der 306-Statuscode wurde in einer früheren Version der Spezifikation verwendet, wird nicht mehr verwendet, und der Code ist reserviert.
10.3.8 307 Temporary Redirect (Temporäre Umleitung)
Die angeforderte Ressource befindet sich vorübergehend unter einem anderen URI. Da die Umleitung von Zeit zu Zeit geändert werden könnte, sollte (SHOULD) der Client den Request-URI für zukünftige Anfragen weiterhin verwenden. Diese Antwort ist nur cachebar, wenn sie durch ein Cache-Control- oder Expires-Headerfeld angegeben wird.
Der temporäre URI sollte (SHOULD) durch das Location-Feld in der Antwort angegeben werden. Sofern die Anfragemethode nicht HEAD war, sollte (SHOULD) die Entität der Antwort einen kurzen Hyperlink zum neuen URI mit einer kurzen Notiz enthalten, da viele Pre-HTTP/1.1-Benutzeragenten den 307-Status nicht verstehen. Daher sollte (SHOULD) die Notiz die Informationen enthalten, die für den Benutzer erforderlich sind, um die ursprüngliche Anfrage auf dem neuen URI zu wiederholen.
Wenn der 307-Statuscode als Antwort auf eine andere Anfrage als GET oder HEAD empfangen wird, darf (MUST NOT) der Benutzeragent die Anfrage nicht automatisch umleiten, es sei denn, sie kann vom Benutzer bestätigt werden, da dies die Bedingungen ändern könnte, unter denen die Anfrage ausgegeben wurde.
10.4 Client Error 4xx (Clientfehler)
Die 4xx-Klasse von Statuscodes ist für Fälle gedacht, in denen der Client einen Fehler gemacht zu haben scheint. Außer beim Antworten auf eine HEAD-Anfrage sollte (SHOULD) der Server eine Entität enthalten, die eine Erklärung der Fehlersituation enthält und ob es sich um eine temporäre oder permanente Bedingung handelt. Diese Statuscodes gelten für jede Anfragemethode. Benutzeragenten sollten (SHOULD) jede enthaltene Entität dem Benutzer anzeigen.
Wenn der Client Daten sendet, sollte (SHOULD) eine TCP-verwendende Serverimplementierung darauf achten, sicherzustellen, dass der Client den Empfang der Pakete, die die Antwort enthalten, bestätigt, bevor der Server die Eingabeverbindung schließt. Wenn der Client nach dem Schließen weiterhin Daten an den Server sendet, sendet der TCP-Stack des Servers ein Reset-Paket an den Client, was die nicht bestätigten Eingabepuffer des Clients löschen könnte, bevor die HTTP-Anwendung sie lesen und interpretieren kann.
10.4.1 400 Bad Request (Fehlerhafte Anfrage)
Die Anfrage konnte vom Server aufgrund fehlerhafter Syntax nicht verstanden werden. Der Client sollte (SHOULD NOT) die Anfrage ohne Änderungen wiederholen.
10.4.2 401 Unauthorized (Nicht autorisiert)
Die Anfrage erfordert Benutzerauthentifizierung. Die Antwort muss (MUST) ein WWW-Authenticate-Headerfeld (Abschnitt 14.47) enthalten, das eine Herausforderung enthält, die auf die angeforderte Ressource anwendbar ist. Der Client kann (MAY) die Anfrage mit einem geeigneten Authorization-Headerfeld (Abschnitt 14.8) wiederholen. Wenn die Anfrage bereits Authorization-Anmeldeinformationen enthielt, zeigt die 401-Antwort an, dass die Autorisierung für diese Anmeldeinformationen verweigert wurde. Wenn die 401-Antwort dieselbe Herausforderung wie eine vorherige Antwort enthält und der Benutzeragent bereits mindestens einmal eine Authentifizierung versucht hat, sollte (SHOULD) die in der Antwort angegebene Entität dem Benutzer präsentiert werden, da diese Entität relevante diagnostische Informationen enthalten könnte. HTTP-Zugriffsauthentifizierung wird in "HTTP Authentication: Basic and Digest Access Authentication" [43] erklärt.
10.4.3 402 Payment Required (Zahlung erforderlich)
Dieser Code ist für zukünftige Verwendung reserviert.
10.4.4 403 Forbidden (Verboten)
Der Server hat die Anfrage verstanden, weigert sich jedoch, sie zu erfüllen. Die Autorisierung wird nicht helfen, und die Anfrage sollte (SHOULD NOT) wiederholt werden. Wenn die Anfragemethode nicht HEAD war und der Server öffentlich machen möchte, warum die Anfrage nicht erfüllt wurde, sollte (SHOULD) er den Grund für die Ablehnung in der Entität beschreiben. Wenn der Server diese Informationen nicht dem Client zur Verfügung stellen möchte, kann stattdessen der Statuscode 404 (Not Found) verwendet werden.
10.4.5 404 Not Found (Nicht gefunden)
Der Server hat nichts gefunden, das dem Request-URI entspricht. Es wird nicht angezeigt, ob die Bedingung temporär oder permanent ist. Der Statuscode 410 (Gone) sollte (SHOULD) verwendet werden, wenn der Server durch einen intern konfigurierbaren Mechanismus weiß, dass eine alte Ressource dauerhaft nicht verfügbar ist und keine Weiterleitungsadresse hat. Dieser Statuscode wird häufig verwendet, wenn der Server nicht genau offenlegen möchte, warum die Anfrage abgelehnt wurde, oder wenn keine andere Antwort anwendbar ist.
10.4.6 405 Method Not Allowed (Methode nicht erlaubt)
Die in der Request-Line angegebene Methode ist für die durch den Request-URI identifizierte Ressource nicht erlaubt. Die Antwort muss (MUST) einen Allow-Header enthalten, der eine Liste der gültigen Methoden für die angeforderte Ressource enthält.
10.4.7 406 Not Acceptable (Nicht akzeptabel)
Die durch die Anfrage identifizierte Ressource kann nur Antwortentitäten generieren, deren Inhaltsmerkmale gemäß den in der Anfrage gesendeten Accept-Headern nicht akzeptabel sind.
Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte (SHOULD) die Antwort eine Entität enthalten, die eine Liste der verfügbaren Entitätsmerkmale und -standorte enthält, aus der der Benutzer oder Benutzeragent das am besten geeignete auswählen kann. Das Entitätsformat wird durch den im Content-Type-Headerfeld angegebenen Medientyp spezifiziert. Abhängig vom Format und den Fähigkeiten des Benutzeragenten kann die Auswahl des am besten geeigneten automatisch vorgenommen werden. Diese Spezifikation definiert jedoch keinen Standard für eine solche automatische Auswahl.
Hinweis: HTTP/1.1-Server dürfen Antworten zurückgeben, die gemäß den in der Anfrage gesendeten Accept-Headern nicht akzeptabel sind. In einigen Fällen kann dies sogar dem Senden einer 406-Antwort vorzuziehen sein. Benutzeragenten werden ermutigt, die Header einer eingehenden Antwort zu inspizieren, um festzustellen, ob sie akzeptabel ist.
Wenn die Antwort inakzeptabel sein könnte, sollte (SHOULD) ein Benutzeragent vorübergehend aufhören, weitere Daten zu empfangen, und den Benutzer nach einer Entscheidung über weitere Maßnahmen fragen.
10.4.8 407 Proxy Authentication Required (Proxy-Authentifizierung erforderlich)
Dieser Code ist ähnlich wie 401 (Unauthorized), zeigt jedoch an, dass sich der Client zuerst beim Proxy authentifizieren muss. Der Proxy muss (MUST) ein Proxy-Authenticate-Headerfeld (Abschnitt 14.33) zurückgeben, das eine Herausforderung enthält, die auf den Proxy für die angeforderte Ressource anwendbar ist. Der Client kann (MAY) die Anfrage mit einem geeigneten Proxy-Authorization-Headerfeld (Abschnitt 14.34) wiederholen. HTTP-Zugriffsauthentifizierung wird in "HTTP Authentication: Basic and Digest Access Authentication" [43] erklärt.
10.4.9 408 Request Timeout (Anfrage-Zeitüberschreitung)
Der Client hat innerhalb der Zeit, die der Server zu warten bereit war, keine Anfrage erstellt. Der Client kann (MAY) die Anfrage ohne Änderungen zu einem späteren Zeitpunkt wiederholen.
10.4.10 409 Conflict (Konflikt)
Die Anfrage konnte aufgrund eines Konflikts mit dem aktuellen Zustand der Ressource nicht abgeschlossen werden. Dieser Code ist nur in Situationen zulässig, in denen erwartet wird, dass der Benutzer den Konflikt lösen und die Anfrage erneut übermitteln kann. Der Antwortkörper sollte (SHOULD) genügend Informationen enthalten, damit der Benutzer die Quelle des Konflikts erkennen kann. Idealerweise würde die Antwortentität genügend Informationen enthalten, damit der Benutzer oder Benutzeragent das Problem lösen kann; dies ist jedoch möglicherweise nicht möglich und nicht erforderlich.
Konflikte treten am wahrscheinlichsten als Antwort auf eine PUT-Anfrage auf. Wenn beispielsweise Versionierung verwendet wurde und die mit PUT versehene Entität Änderungen an einer Ressource enthält, die mit Änderungen in Konflikt stehen, die durch eine frühere (Drittanbieter-)Anfrage vorgenommen wurden, könnte der Server eine 409-Antwort verwenden, um anzuzeigen, dass er die Anfrage nicht abschließen kann. In diesem Fall würde die Antwortentität wahrscheinlich eine Liste der Unterschiede zwischen den beiden Versionen in einem vom Content-Type der Antwort definierten Format enthalten.
10.4.11 410 Gone (Verschwunden)
Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar, und es ist keine Weiterleitungsadresse bekannt. Diese Bedingung wird als dauerhaft erwartet. Clients mit Link-Bearbeitungsfähigkeiten sollten (SHOULD) nach Genehmigung des Benutzers Verweise auf den Request-URI löschen, wenn möglich. Wenn der Server nicht weiß oder keine Möglichkeit hat festzustellen, ob die Bedingung dauerhaft ist, sollte (SHOULD) stattdessen der Statuscode 404 (Not Found) verwendet werden. Diese Antwort ist cachebar, sofern nicht anders angegeben.
Die 410-Antwort ist hauptsächlich dazu gedacht, die Webwartungsaufgabe zu unterstützen, indem sie dem Empfänger mitteilt, dass die Ressource absichtlich nicht verfügbar ist und dass die Servereigentümer wünschen, dass entfernte Links zu dieser Ressource entfernt werden. Ein solches Ereignis ist bei zeitlich begrenzten Werbeaktionen und bei Ressourcen, die Personen gehören, die nicht mehr auf der Website des Ursprungsservers arbeiten, üblich. Es ist nicht notwendig, alle dauerhaft nicht verfügbaren Ressourcen als "gone" zu markieren oder die Markierung für eine bestimmte Zeitdauer beizubehalten - dies bleibt der Entscheidung des Servereigentümers überlassen.
10.4.12 411 Length Required (Länge erforderlich)
Der Server weigert sich, die Anfrage ohne definierten Content-Length zu akzeptieren. Der Client kann (MAY) die Anfrage wiederholen, wenn er ein gültiges Content-Length-Headerfeld mit der Länge des Nachrichtenkörpers in der Anfragenachricht hinzufügt.
10.4.13 412 Precondition Failed (Vorbedingung fehlgeschlagen)
Die in einem oder mehreren der Anfrage-Headerfelder angegebene Vorbedingung wurde beim Testen auf dem Server als falsch bewertet. Dieser Statuscode ermöglicht es dem Client, Vorbedingungen für die aktuellen Ressourcenmetainformationen (Headerfeldaten) festzulegen und so zu verhindern, dass die Anfragemethode auf eine andere als die beabsichtigte Ressource angewendet wird.
10.4.14 413 Request Entity Too Large (Anfrage-Entität zu groß)
Der Server weigert sich, eine Anfrage zu verarbeiten, da die Anfrage-Entität größer ist, als der Server verarbeiten möchte oder kann. Der Server kann (MAY) die Verbindung schließen, um zu verhindern, dass der Client mit der Anfrage fortfährt.
Wenn die Bedingung temporär ist, sollte (SHOULD) der Server ein Retry-After-Headerfeld enthalten, um anzuzeigen, dass sie temporär ist und wann der Client es erneut versuchen kann.
10.4.15 414 Request-URI Too Long (Request-URI zu lang)
Der Server weigert sich, die Anfrage zu bedienen, da der Request-URI länger ist, als der Server zu interpretieren bereit ist. Diese seltene Bedingung tritt nur auf, wenn: ein Client fälschlicherweise eine POST-Anfrage in eine GET-Anfrage mit langen Abfrageinformationen umgewandelt hat, wenn der Client in ein "Schwarzes Loch" der Umleitung abgestiegen ist (z. B. ein Umleitungspräfix, das auf ein Suffix von sich selbst zeigt), oder wenn der Server von einem Client angegriffen wird, der versucht, Sicherheitslücken auszunutzen, die in einigen Servern vorhanden sind, die Puffer fester Länge zum Lesen oder Manipulieren des Request-URI verwenden.
10.4.16 415 Unsupported Media Type (Nicht unterstützter Medientyp)
Der Server weigert sich, die Anfrage zu bedienen, da die Entität der Anfrage in einem Format vorliegt, das von der angeforderten Ressource für die angeforderte Methode nicht unterstützt wird.
10.4.17 416 Requested Range Not Satisfiable (Angeforderten Bereich nicht erfüllbar)
Ein Server sollte (SHOULD) mit diesem Statuscode antworten, wenn eine Anfrage ein Range-Anfrage-Headerfeld (Abschnitt 14.35) enthielt und keiner der Bereichswerte im Bereichsspezifikator-Wert mit dem aktuellen Bereich der ausgewählten Ressource überlappt und die Anfrage kein If-Range-Anfrage-Headerfeld enthielt. (Für Bytebereiche bedeutet dies, dass die Position des ersten Bytes aller byte-range-spec-Werte größer war als die aktuelle Länge der ausgewählten Ressource.)
Wenn dieser Statuscode für einen Bytebereich zurückgegeben wird, sollte (SHOULD) die Antwort ein Content-Range-Entitätsheaderfeld enthalten, das die aktuelle Länge der ausgewählten Ressource angibt (siehe Abschnitt 14.16). Diese Antwort darf (MUST NOT) den multipart/byteranges-Content-Type verwenden.
10.4.18 417 Expectation Failed (Erwartung fehlgeschlagen)
Die in einem Expect-Anfrage-Headerfeld (siehe Abschnitt 14.20) angegebene Erwartung konnte von diesem Server nicht erfüllt werden, oder, wenn der Server ein Proxy ist, hat der Server eindeutige Beweise dafür, dass die Anfrage vom Next-Hop-Server nicht erfüllt werden kann.
10.5 Server Error 5xx (Serverfehler)
Antwortstatuscodes, die mit der Ziffer "5" beginnen, zeigen Fälle an, in denen der Server weiß, dass er einen Fehler gemacht hat oder nicht in der Lage ist, die Anfrage auszuführen. Außer beim Antworten auf eine HEAD-Anfrage sollte (SHOULD) der Server eine Entität enthalten, die eine Erklärung der Fehlersituation enthält und ob es sich um eine temporäre oder permanente Bedingung handelt. Benutzeragenten sollten (SHOULD) jede enthaltene Entität dem Benutzer anzeigen. Diese Antwortcodes gelten für jede Anfragemethode.
10.5.1 500 Internal Server Error (Interner Serverfehler)
Der Server ist auf eine unerwartete Bedingung gestoßen, die ihn daran hinderte, die Anfrage zu erfüllen.
10.5.2 501 Not Implemented (Nicht implementiert)
Der Server unterstützt nicht die Funktionalität, die zur Erfüllung der Anfrage erforderlich ist. Dies ist die angemessene Antwort, wenn der Server die Anfragemethode nicht erkennt und sie für keine Ressource unterstützen kann.
10.5.3 502 Bad Gateway (Fehlerhafte Gateway)
Der Server hat beim Fungieren als Gateway oder Proxy eine ungültige Antwort vom Upstream-Server erhalten, auf den er beim Versuch, die Anfrage zu erfüllen, zugegriffen hat.
10.5.4 503 Service Unavailable (Dienst nicht verfügbar)
Der Server ist derzeit nicht in der Lage, die Anfrage aufgrund einer temporären Überlastung oder Wartung des Servers zu bearbeiten. Dies bedeutet, dass es sich um eine temporäre Bedingung handelt, die nach einer gewissen Verzögerung behoben wird. Wenn bekannt, kann (MAY) die Länge der Verzögerung in einem Retry-After-Header angegeben werden. Wenn kein Retry-After angegeben wird, sollte (SHOULD) der Client die Antwort so behandeln, als wäre es eine 500-Antwort.
Hinweis: Das Vorhandensein des 503-Statuscodes impliziert nicht, dass ein Server ihn bei Überlastung verwenden muss. Einige Server möchten möglicherweise einfach die Verbindung ablehnen.
10.5.5 504 Gateway Timeout (Gateway-Zeitüberschreitung)
Der Server hat beim Fungieren als Gateway oder Proxy nicht rechtzeitig eine Antwort vom Upstream-Server erhalten, auf den er für die Vervollständigung der Anfrage zugreifen musste.
Hinweis: Beachten Sie, dass 408 (Request Timeout) von diesem Statuscode unterschieden werden sollte.
10.5.6 505 HTTP Version Not Supported (HTTP-Version nicht unterstützt)
Der Server unterstützt die in der Anfragenachricht verwendete HTTP-Protokollversion nicht oder weigert sich, sie zu unterstützen. Der Server gibt an, dass er nicht in der Lage ist oder nicht bereit ist, die Anfrage mit derselben Hauptversion wie der Client abzuschließen, wie in Abschnitt 3.1 beschrieben, außer mit dieser Fehlermeldung. Die Antwort sollte (SHOULD) eine Entität enthalten, die beschreibt, warum diese Version nicht unterstützt wird und welche anderen Protokolle von diesem Server unterstützt werden.