Tipp: Mit Ctrl+F schnell suchen| Http-Statuscode | Bedeutung des Statuscodes |
|---|---|
| 100 | Der Client soll die Anfrage weitersenden. Diese temporäre Antwort teilt dem Client mit, dass ein Teil seiner Anfrage vom Server empfangen und nicht abgelehnt wurde. Der Client soll den Rest der Anfrage weitersenden oder, falls die Anfrage abgeschlossen ist, diese Antwort ignorieren. Der Server muss dem Client nach Abschluss der Anfrage eine endgültige Antwort senden. |
| 101 | Der Server hat die Client-Anfrage verstanden und wird den Client über den Upgrade-Header benachrichtigen, diese Anfrage mit einem anderen Protokoll abzuschließen. Nach dem Senden der letzten leeren Zeile dieser Antwort wechselt der Server zu den im Upgrade-Header definierten Protokollen. Solche Maßnahmen sollten nur ergriffen werden, wenn der Wechsel zu einem neuen Protokoll tatsächlich Vorteile bringt, etwa zu einer neuen, vorteilhafteren HTTP-Version oder zu einem Echtzeit-Synchron-Protokoll für Ressourcen, die solche Merkmale nutzen. |
| 102 | Ein von WebDAV (RFC 2518) erweiterter Statuscode, der anzeigt, dass die Verarbeitung fortgesetzt wird. |
| 200 | Die Anfrage war erfolgreich; die gewünschten Antwort-Header oder der Datenteil werden mit dieser Antwort gesendet. |
| 201 | Die Anfrage wurde ausgeführt und eine neue Ressource entsprechend der Anfrage erstellt; ihre URI wurde im Location-Header zurückgegeben. Kann die benötigte Ressource nicht rechtzeitig erstellt werden, sollte '202 Accepted' zurückgegeben werden. |
| 202 | Der Server hat die Anfrage angenommen, aber noch nicht verarbeitet. Wie bei einer möglichen Ablehnung kann die Anfrage am Ende ausgeführt werden oder auch nicht. Bei asynchronen Vorgängen gibt es keine bequemere Wahl als diesen Statuscode zu senden. Eine 202-Antwort erlaubt es dem Server, die Anfrage für einen anderen Vorgang anzunehmen (z. B. einen Batch-Vorgang, der nur einmal täglich läuft), ohne dass der Client die Verbindung bis zum Abschluss aufrechterhalten muss. Die Antwort, die die Anfrage annimmt und Statuscode 202 zurückgibt, sollte in der Entität Informationen zum aktuellen Verarbeitungsstatus sowie einen Zeiger auf eine Statusüberwachung oder -prognose enthalten, damit der Nutzer abschätzen kann, ob der Vorgang abgeschlossen ist. |
| 203 | Der Server hat die Anfrage erfolgreich verarbeitet, aber die zurückgegebenen Metadaten im Entity-Header sind keine verbindliche, auf dem Ursprungsserver gültige Menge, sondern stammen aus einer lokalen oder Drittanbieter-Kopie. Die aktuellen Informationen können eine Teilmenge oder Obermenge der Originalversion sein. Beispielsweise können die im Objekt enthaltenen Metadaten dem Ursprungsserver eine Obermenge der Metadaten bekannt machen. Die Verwendung dieses Statuscodes ist nicht erforderlich und nur dann angebracht, wenn die Antwort ohne diesen Statuscode 200 OK zurückgeben würde. |
| 204 | Der Server hat die Anfrage erfolgreich verarbeitet, muss aber keinen Entity-Inhalt zurückgeben und möchte aktualisierte Metainformationen liefern. Die Antwort kann neue oder aktualisierte Metainformationen in Form von Entity-Headern zurückgeben. Falls diese Header existieren, sollten sie zu den angefragten Variablen passen. Ist der Client ein Browser, sollte dieser die Seite, die die Anfrage gesendet hat, behalten, ohne Veränderung der Dokumentansicht, obwohl gemäß Spezifikation neue oder aktualisierte Metainformationen auf das Dokument in der aktiven Ansicht des Browsers angewendet werden sollten. Da eine 204-Antwort keinen Nachrichtenkörper enthalten darf, endet sie stets mit der ersten leeren Zeile nach den Headern der Nachricht. |
| 205 | Der Server hat die Anfrage erfolgreich verarbeitet und keinen Inhalt zurückgegeben. Anders als bei der 204-Antwort muss der Anfragende bei diesem Statuscode die Dokumentansicht zurücksetzen. Sie wird hauptsächlich verwendet, um das Formular unmittelbar nach dem Akzeptieren der Benutzereingabe zurückzusetzen, damit der Benutzer leicht eine neue Eingabe beginnen kann. Wie die 204-Antwort darf auch diese Antwort keinen Nachrichtentext enthalten und endet mit der ersten leeren Zeile nach den Nachrichtenkopfzeilen. |
| 206 | Der Server hat eine teilweise GET-Anfrage erfolgreich verarbeitet. HTTP-Download-Tools wie FlashGet oder Thunder verwenden diese Art von Antwort, um das Fortsetzen von Downloads zu ermöglichen oder ein großes Dokument in mehrere Segmente für den gleichzeitigen Download aufzuteilen. Die Anfrage muss das Header-Feld Range enthalten, um den vom Client gewünschten Inhaltsbereich anzugeben, und kann If-Range als Anfragebedingung enthalten. Die Antwort muss die folgenden Header-Felder enthalten: Content-Range zur Angabe des in dieser Antwort zurückgegebenen Inhaltsbereichs; handelt es sich um einen Mehrsegment-Download mit Content-Type multipart/byteranges, muss jedes multipart-Segment ein Content-Range-Feld enthalten, das den Inhaltsbereich dieses Segments angibt. Enthält die Antwort Content-Length, muss ihr Wert mit der tatsächlichen Byteanzahl des zurückgegebenen Inhaltsbereichs übereinstimmen. Date, ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200-Antwort zurückgegeben hätte. Expires, Cache-Control und/oder Vary, wenn ihre Werte von denen anderer Antworten auf dieselbe Variable zuvor abweichen können. Verwendete die Anfrage dieser Antwort eine starke If-Range-Cache-Validierung, sollte die Antwort keine anderen Entity-Header enthalten; verwendete die Anfrage eine schwache If-Range-Cache-Validierung, darf die Antwort keine anderen Entity-Header enthalten; dies verhindert Unstimmigkeiten zwischen dem gecachten Entity-Inhalt und aktualisierten Entity-Headern. Andernfalls sollte die Antwort alle Entity-Header-Felder enthalten, die eine 200-Antwort zurückgegeben hätte. Stimmen die Header ETag oder Last-Modified nicht exakt überein, darf der Client-Cache den von der 206-Antwort zurückgegebenen Inhalt nicht mit zuvor gecachtem Inhalt kombinieren. Jeder Cache, der die Header Range und Content-Range nicht unterstützt, darf den von einer 206-Antwort zurückgegebenen Inhalt nicht cachen. |
| 207 | Ein durch WebDAV (RFC 2518) erweiterter Statuscode, der anzeigt, dass der folgende Nachrichtentext eine XML-Nachricht ist und je nach Anzahl vorangehender Unteraufrufe möglicherweise eine Reihe unabhängiger Antwortcodes enthält. |
| 300 | Die angeforderte Ressource bietet eine Auswahl an möglichen Antworten, von denen jede über ihre eigene spezifische Adresse und browsergesteuerte Verhandlungsinformationen verfügt. Der Benutzer oder Browser kann selbst eine bevorzugte Adresse für die Weiterleitung auswählen. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort eine Entity enthalten, die eine Liste der Ressourceneigenschaften und -adressen ist, damit der Benutzer oder Browser die geeignetste Weiterleitungsadresse daraus wählen kann. Das Format dieser Entity wird durch das von Content-Type definierte Format bestimmt. Der Browser kann basierend auf dem Antwortformat und seinen eigenen Fähigkeiten automatisch die beste Wahl treffen. Die Spezifikation RFC 2616 legt allerdings nicht fest, wie eine solche automatische Auswahl ablaufen soll. Verfügt der Server selbst über eine bevorzugte Antwortauswahl, sollte das Location-Feld die URI dieser Auswahl angeben; der Browser könnte diesen Location-Wert als Adresse für die automatische Weiterleitung verwenden. Zudem ist diese Antwort, sofern nicht anders angegeben, cachebar. |
| 301 | Die angeforderte Ressource wurde dauerhaft an einen neuen Speicherort verschoben, und künftige Verweise auf diese Ressource sollten eine der von dieser Antwort zurückgegebenen URIs verwenden. Falls möglich, sollte jeder Client mit Link-Bearbeitungsfunktion die Anfrageadresse automatisch auf die vom Server zurückgemeldete Adresse ändern. Sofern nicht anders angegeben, ist diese Antwort cachebar. Die neue dauerhafte URI sollte im Location-Feld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte der Antwort-Entity einen Hyperlink auf die neue URI und eine kurze Beschreibung enthalten. Handelt es sich nicht um eine GET- oder HEAD-Anfrage, darf der Browser die Weiterleitung nicht automatisch ausführen, es sei denn, der Benutzer bestätigt sie, da sich die Bedingungen der Anfrage dadurch ändern können. Hinweis: Bei einigen Browsern, die das HTTP/1.0-Protokoll verwenden, wird die folgende Weiterleitungsanfrage zu einer GET-Anfrage, wenn die von ihnen gesendete POST-Anfrage eine 301-Antwort erhält. |
| 302 | Die angeforderte Ressource wird vorübergehend von einer anderen URI bedient. Da diese Weiterleitung nur vorübergehend ist, sollte der Client künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort ist nur dann cachebar, wenn dies in Cache-Control oder Expires angegeben ist. Die neue vorübergehende URI sollte im Location-Feld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte der Antwort-Entity einen Hyperlink auf die neue URI sowie eine kurze Beschreibung enthalten. Handelt es sich nicht um eine GET- oder HEAD-Anfrage, darf der Browser die Weiterleitung nicht automatisch ausführen, es sei denn, der Benutzer bestätigt sie, da sich die Bedingungen der Anfrage dadurch ändern können. Hinweis: Obwohl die Spezifikationen RFC 1945 und RFC 2068 es dem Client nicht erlauben, bei einer Weiterleitung die Anfrage-Methode zu ändern, behandeln viele vorhandene Browser die 302-Antwort wie eine 303-Antwort und rufen die in Location angegebene URI mit GET auf, wobei sie die ursprüngliche Anfrage-Methode ignorieren. Die Statuscodes 303 und 307 wurden hinzugefügt, um zu verdeutlichen, wie der Server die Reaktion des Clients erwartet. |
| 303 | Die Antwort auf die aktuelle Anfrage kann unter einer anderen URI gefunden werden, und der Client sollte diese Ressource per GET abrufen. Diese Methode existiert hauptsächlich, damit die Ausgabe einer durch ein Skript ausgelösten POST-Anfrage auf eine neue Ressource weitergeleitet werden kann. Die neue URI ist keine ersatzweise Referenz auf die ursprüngliche Ressource. Zugleich darf die 303-Antwort nicht gecacht werden. Natürlich kann die zweite Anfrage (die Weiterleitung) cachebar sein. Die neue URI sollte im Location-Feld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte der Antwort-Entity einen Hyperlink auf die neue URI und eine kurze Beschreibung enthalten. Hinweis: Viele Browser vor HTTP/1.1 verstehen den Status 303 nicht korrekt. Muss die Interaktion mit diesen Browsern berücksichtigt werden, sollte der Statuscode 302 ausreichen, denn die Art, wie die meisten Browser eine 302-Antwort verarbeiten, entspricht genau dem, was die obige Spezifikation von Clients bei der Verarbeitung einer 303-Antwort verlangt. |
| 304 | Hat der Client eine bedingte GET-Anfrage gesendet und ist diese Anfrage zulässig, aber der Dokumentinhalt hat sich (seit dem letzten Zugriff oder gemäß den Anfragebedingungen) nicht geändert, sollte der Server diesen Statuscode zurückgeben. Die 304-Antwort darf keinen Nachrichtentext enthalten und endet daher immer nach der ersten Leerzeile nach den Headern. Die Antwort muss die folgenden Header-Felder enthalten: Date, es sei denn, der Server hat keine Uhr. Befolgt ein Server ohne Uhr diese Regeln ebenfalls, können Proxy-Server und Clients das Date-Feld selbstständig den empfangenen Antwort-Headern hinzufügen (wie in RFC 2068 festgelegt), und der Caching-Mechanismus funktioniert einwandfrei. ETag und/oder Content-Location, wenn dieselbe Anfrage eine 200-Antwort zurückgegeben hätte. Expires, Cache-Control und/oder Vary, wenn ihre Werte von denen anderer Antworten auf dieselbe Variable zuvor abweichen können. Verwendete die Anfrage dieser Antwort eine starke Cache-Validierung, sollte die Antwort keine anderen Entity-Header enthalten; andernfalls (z. B. wenn eine bedingte GET-Anfrage eine schwache Cache-Validierung verwendete) darf die Antwort keine anderen Entity-Header enthalten; dies verhindert Unstimmigkeiten zwischen dem gecachten Entity-Inhalt und aktualisierten Entity-Headern. Zeigt eine 304-Antwort an, dass eine aktuelle Entity nicht gecacht ist, muss das Caching-System diese Antwort ignorieren und die Anfrage ohne Bedingungen erneut senden. Geht eine 304-Antwort ein, die das Aktualisieren eines Cache-Eintrags verlangt, muss das Caching-System den gesamten Eintrag aktualisieren, um alle in der Antwort aktualisierten Feldwerte abzubilden. |
| 305 | Die angefragte Ressource muss über den angegebenen Proxy aufgerufen werden. Das Location-Feld nennt die URI des angegebenen Proxys, und der Empfänger muss eine separate Anfrage über diesen Proxy wiederholen, um die Ressource zu erreichen. Nur der Origin-Server darf eine 305-Antwort erstellen. Hinweis: RFC 2068 legt nicht eindeutig fest, dass eine 305-Antwort dem Umleiten einer Einzelanfrage dient und nur vom Origin-Server erstellt werden darf. Diese Grenzen zu ignorieren, kann schwerwiegende Sicherheitsfolgen haben. |
| 306 | In der neuesten Version der Spezifikation wird der Statuscode 306 nicht mehr verwendet. |
| 307 | Die angeforderte Ressource wird vorübergehend von einer anderen URI bedient. Da diese Weiterleitung nur vorübergehend ist, sollte der Client künftige Anfragen weiterhin an die ursprüngliche Adresse senden. Diese Antwort ist nur dann cachebar, wenn dies in Cache-Control oder Expires angegeben ist. Die neue vorübergehende URI sollte im Location-Feld der Antwort zurückgegeben werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte der Antwort-Entity einen Hyperlink auf die neue URI und eine kurze Beschreibung enthalten. Da manche Browser die 307-Antwort nicht erkennen, müssen die oben genannten erforderlichen Informationen hinzugefügt werden, damit der Benutzer sie verstehen und eine Anfrage an die neue URI senden kann. Handelt es sich nicht um eine GET- oder HEAD-Anfrage, darf der Browser die Weiterleitung nicht automatisch ausführen, es sei denn, der Benutzer bestätigt sie, da sich die Bedingungen der Anfrage dadurch ändern können. |
| 400 | 1. Die Anfrage kann wegen fehlerhafter Syntax nicht vom Server verstanden werden; der Client sollte sie ohne Änderungen nicht wiederholen. 2. Die Anfrageparameter sind ungültig. |
| 401 | Die aktuelle Anfrage erfordert eine Benutzerauthentifizierung. Die Antwort muss ein WWW-Authenticate-Header-Feld enthalten, das auf die angeforderte Ressource anwendbar ist, um den Benutzer nach Informationen zu fragen. Der Client kann eine Anfrage mit einem geeigneten Authorization-Headerfeld erneut senden. Enthielt die aktuelle Anfrage bereits Authorization-Anmeldedaten, bedeutet die 401-Antwort, dass die Überprüfung durch den Server diese Anmeldedaten abgelehnt hat. Enthält eine 401-Antwort dieselbe Authentifizierungsabfrage wie eine frühere Antwort und hat der Browser die Authentifizierung bereits mindestens einmal versucht, sollte der Browser dem Benutzer die in der Antwort enthaltene Entity-Information anzeigen, da diese Entity-Information möglicherweise relevante Diagnoseinformationen enthält. Siehe RFC 2617. |
| 402 | Dieser Statuscode ist für zukünftige Anforderungen reserviert. |
| 403 | Der Server hat die Anfrage verstanden, lehnt ihre Ausführung aber ab. Anders als bei der 401-Antwort bringt eine Authentifizierung hier nichts, und die Anfrage sollte nicht erneut gesendet werden. Wenn es sich nicht um eine HEAD-Anfrage handelt und der Server erklären möchte, warum die Anfrage nicht ausgeführt werden kann, sollte der Grund in der Entity beschrieben werden. Der Server kann auch eine 404-Antwort zurückgeben, wenn der Client keinerlei Informationen erhalten soll. |
| 404 | Die Anfrage ist fehlgeschlagen; die angefragte Ressource wurde auf dem Server nicht gefunden. Keine Information verrät dem Nutzer, ob der Zustand vorübergehend oder dauerhaft ist. Kennt der Server die Lage, sollte er den Statuscode 410 verwenden, um anzuzeigen, dass die alte Ressource wegen interner Konfigurationsprobleme dauerhaft nicht verfügbar ist und keine Weiterleitungsadresse existiert. Der 404-Statuscode wird häufig eingesetzt, wenn der Server den Ablehnungsgrund nicht offenlegen will oder keine andere passende Antwort verfügbar ist. |
| 405 | Die in der Anfragezeile angegebene Anfragemethode kann für die entsprechende Ressource nicht verwendet werden. Diese Antwort muss einen Allow-Header zurückgeben, in dem die Anfragemethoden aufgeführt sind, welche die aktuelle Ressource akzeptiert. Da PUT- und DELETE-Methoden Schreiboperationen auf Ressourcen des Servers ausführen, unterstützen die meisten Webserver diese Anfragemethoden nicht oder erlauben sie nicht in der Standardkonfiguration; solche Anfragen liefern alle einen 405-Fehler. |
| 406 | Die Inhaltsmerkmale der angefragten Ressource erfüllen die Bedingungen der Anfrage-Header nicht, daher kann keine Antwort-Entität erzeugt werden. Sofern es sich nicht um eine HEAD-Anfrage handelt, sollte die Antwort eine Entität mit einer Liste von Entity-Merkmalen und Adressen zurückgeben, aus der Nutzer oder Browser das Passendste wählen. Das Format der Entität bestimmt der in Content-Type definierte Medientyp. Der Browser kann nach Format und eigenen Fähigkeiten die beste Wahl treffen, doch definiert die Spezifikation keinen Standard für eine solche automatische Auswahl. |
| 407 | Ähnlich der 401-Antwort, nur dass sich der Client beim Proxy-Server authentifizieren muss. Der Proxy-Server muss ein Proxy-Authenticate zurückgeben, um die Authentifizierungsabfrage durchzuführen. Der Client kann einen Proxy-Authorization-Header zur Authentifizierung zurücksenden. Siehe RFC 2617. |
| 408 | Zeitüberschreitung der Anfrage. Der Client hat eine Anfrage nicht innerhalb der Zeit abgeschlossen, die der Server bereit war zu warten. Der Client kann die Anfrage jederzeit unverändert erneut senden. |
| 409 | Die Anfrage konnte aufgrund eines Konflikts mit dem aktuellen Zustand der angeforderten Ressource nicht abgeschlossen werden. Dieser Code darf nur in Fällen verwendet werden, in denen der Benutzer den Konflikt voraussichtlich lösen und eine neue Anfrage erneut senden kann. Die Antwort sollte genügend Informationen enthalten, damit der Benutzer die Quelle des Konflikts finden kann. Konflikte treten üblicherweise bei der Verarbeitung von PUT-Anfragen auf. Wenn beispielsweise in einer Umgebung mit Versionsprüfung die einer PUT-Anfrage beigefügte Versionsinformation für die Änderung einer bestimmten Ressource mit der einer früheren (Drittanbieter-)Anfrage kollidiert, sollte der Server einen 409-Fehler zurückgeben und den Benutzer informieren, dass die Anfrage nicht abgeschlossen werden kann. In diesem Fall enthält die Antwort-Entity vermutlich einen Vergleich der Unterschiede zwischen den beiden konfliktbehafteten Versionen, damit der Benutzer eine neue, zusammengeführte Version erneut senden kann. |
| 410 | Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar, und keine Weiterleitungsadresse ist bekannt. Dieser Zustand sollte als dauerhaft betrachtet werden. Falls möglich, sollte jeder Client mit Link-Bearbeitungsfunktion nach Erlaubnis des Benutzers alle Verweise auf diese Adresse entfernen. Wenn der Server nicht weiß oder nicht feststellen kann, ob der Zustand dauerhaft ist, sollte stattdessen der Statuscode 404 verwendet werden. Sofern nicht anders angegeben, ist diese Antwort cachebar. Der Zweck der 410-Antwort ist in erster Linie, Webmastern bei der Pflege ihrer Website zu helfen, indem Benutzer darüber informiert werden, dass die Ressource nicht mehr verfügbar ist und der Serverbesitzer wünscht, dass alle externen Verknüpfungen auf diese Ressource entfernt werden. Solche Fälle sind bei zeitlich begrenzten Mehrwertdiensten üblich. Ebenso wird die 410-Antwort verwendet, um den Client darüber zu informieren, dass eine Ressource auf der aktuellen Server-Site, die ursprünglich einer Person gehörte, nicht mehr verfügbar ist. Ob alle dauerhaft nicht verfügbaren Ressourcen als '410 Gone' gekennzeichnet werden sollen und wie lange diese Kennzeichnung beibehalten werden soll, liegt natürlich ganz beim Serverbesitzer. |
| 411 | Der Server lehnt die Anfrage ohne definierten Content-Length-Header ab. Nach Hinzufügen eines gültigen Content-Length-Headers mit der Länge des Anfrage-Bodys kann der Client die Anfrage erneut senden. |
| 412 | Der Server konnte eine oder mehrere der in den Headerfeldern der Anfrage angegebenen Vorbedingungen bei deren Prüfung nicht erfüllen. Dieser Statuscode erlaubt es einem Client, Vorbedingungen in den Metadaten der Anfrage (Anfrage-Headerfelder) festzulegen, bevor er die Ressource abruft, um zu vermeiden, dass die Anfragemethode auf andere Inhalte als die beabsichtigte Ressource angewendet wird. |
| 413 | Der Server verweigert die Verarbeitung der aktuellen Anfrage, weil die Größe der von der Anfrage übermittelten Entity-Daten den Bereich überschreitet, den der Server bereit oder in der Lage ist zu verarbeiten. In diesem Fall kann der Server die Verbindung schließen, damit der Client diese Anfrage nicht weiter sendet. Ist der Zustand nur vorübergehend, sollte der Server einen Retry-After-Antwort-Header zurückgeben, um dem Client mitzuteilen, wann er es erneut versuchen kann. |
| 414 | Die Länge der Anfrage-URI übersteigt das, was der Server interpretieren kann, weshalb der Server die Bearbeitung der Anfrage verweigert. Dies ist relativ selten; typische Fälle sind: ein Formular-Submit, der die POST-Methode verwenden sollte, wird zur GET-Methode, wodurch die Abfragezeichenkette (Query String) zu lang wird. Ein "Black Hole" bei Weiterleitungs-URIs, bei dem jede Weiterleitung die alte URI als Teil der neuen URI anhängt und so die URI nach mehreren Weiterleitungen zu lang wird. Der Client versucht, den Server durch Ausnutzen einer Sicherheitslücke in bestimmten Servern anzugreifen. Solche Server lesen oder verarbeiten die Anfrage-URI mit einem Puffer fester Länge; überschreiten die Parameter nach GET einen bestimmten Wert, kann ein Pufferüberlauf auftreten, der zur Ausführung von beliebigem Code führt[1]. Ein Server ohne eine solche Schwachstelle sollte den Statuscode 414 zurückgeben. |
| 415 | Die in der Anfrage übermittelte Entität liegt nicht in einem vom Server für die angefragte Methode und Ressource unterstützten Format vor, daher wird die Anfrage abgelehnt. |
| 416 | Enthielt die Anfrage einen Range-Request-Header und überlappen keine der im Range angegebenen Datenbereiche den verfügbaren Bereich der aktuellen Ressource, zudem die Anfrage keinen If-Range-Request-Header definiert, sollte der Server den Statuscode 416 zurückgeben. Verwendet der Range Bytebereiche, bedeutet dies, dass die Position des ersten Bytes aller in der Anfrage angegebenen Datenbereiche die Länge der aktuellen Ressource überschreitet. Beim Zurückgeben des Statuscodes 416 sollte der Server zusätzlich einen Content-Range-Entity-Header enthalten, der die Länge der aktuellen Ressource angibt. Diese Antwort darf zudem nicht multipart/byteranges als Content-Type verwenden. |
| 417 | Die im Expect-Header der Anfrage angegebene Erwartung kann vom Server nicht erfüllt werden, oder der Server ist ein Proxy mit klaren Hinweisen, dass der Expect-Inhalt am nächsten Knoten der aktuellen Route nicht erfüllt werden kann. |
| 421 | Die Anzahl der Verbindungen von der aktuellen IP-Adresse des Clients zum Server überschreitet das vom Server erlaubte Maximum. In der Regel ist die IP-Adresse hier die vom Client, wie der Server sie sieht (z. B. die Adresse des Gateways oder Proxy-Servers des Nutzers). Dabei kann die Verbindungszählung mehr als einen Endnutzer betreffen. |
| 422 | Die Anzahl der Verbindungen von der aktuellen IP-Adresse des Clients zum Server überschreitet das vom Server erlaubte Maximum. In der Regel ist die IP-Adresse hier die vom Client, wie der Server sie sieht (z. B. die Adresse des Gateways oder Proxy-Servers des Nutzers). Dabei kann die Verbindungszählung mehr als einen Endnutzer betreffen. |
| 422 | Die Anfrage ist korrekt formatiert, kann aber aufgrund semantischer Fehler nicht beantwortet werden. (RFC 4918 WebDAV) 423 Locked Die aktuelle Ressource ist gesperrt. (RFC 4918 WebDAV) |
| 424 | Die aktuelle Anfrage schlug wegen eines Fehlers einer früheren Anfrage fehl, zum Beispiel PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Im WebDav-Advanced-Collections-Entwurf definiert, aber nicht im WebDAV Ordered Collections Protocol (RFC 3658) enthalten. |
| 426 | Der Client sollte auf TLS/1.0 wechseln. (RFC 2817) |
| 449 | Von Microsoft erweitert: Die Anfrage sollte nach Ausführung der passenden Aktion wiederholt werden. |
| 500 | Der Server stieß auf einen unerwarteten Zustand und konnte die Anfrage nicht abschließen. Dieses Problem tritt im Allgemeinen auf, wenn der Programmcode des Servers einen Fehler wirft. |
| 501 | Der Server unterstützt die für die Anfrage erforderliche Funktion nicht. Die Anfrage-Methode wird nicht erkannt und kann für keine Ressource unterstützt werden. |
| 502 | Der als Gateway oder Proxy arbeitende Server erhielt beim Versuch, die Anfrage auszuführen, eine ungültige Antwort eines Upstream-Servers. |
| 503 | Wegen vorübergehender Server-Wartung oder Überlast kann der Server die Anfrage derzeit nicht bearbeiten. Der Zustand ist vorübergehend und wird nach einiger Zeit behoben sein. Ist die Verzögerung absehbar, kann die Antwort einen Retry-After-Header enthalten, der diese Verzögerung angibt. Ohne diese Retry-After-Information sollte der Client die Antwort wie eine 500-Antwort behandeln. Hinweis: Der 503-Statuscode bedeutet nicht, dass ein Server bei Überlast ihn verwenden muss; manche Server möchten einfach Client-Verbindungen ablehnen. |
| 504 | Ein Server, der als Gateway oder Proxy arbeitet, erhielt während des Versuchs, die Anfrage auszuführen, rechtzeitig keine Antwort von einem Upstream-Server (der durch die URI identifizierte Server, z. B. HTTP, FTP, LDAP) oder einem Hilfsserver (z. B. DNS). Hinweis: Manche Proxy-Server geben einen 400- oder 500-Fehler zurück, wenn eine DNS-Abfrage abläuft. |
| 505 | Der Server unterstützt die in der Anfrage verwendete HTTP-Version nicht oder lehnt sie ab. Dies deutet darauf hin, dass der Server dieselbe Version wie der Client nicht verwenden kann oder will. Die Antwort sollte eine Entität enthalten, die erklärt, warum die Version nicht unterstützt wird und welche Protokolle der Server unterstützt. |
| 506 | Erweitert durch das Protokoll zur transparenten Inhaltsaushandlung (RFC 2295): Der Server weist einen internen Konfigurationsfehler auf: Die ausgehandelte Varianten-Ressource ist so konfiguriert, dass sie sich selbst verwendet, und ist daher kein geeignetes Ziel innerhalb einer Aushandlung. |
| 507 | Der Server kann die zum Abschluss der Anfrage erforderlichen Inhalte nicht speichern. Dieser Zustand wird als temporär angesehen. WebDAV (RFC 4918) |
| 509 | Der Server hat seine Bandbreitengrenze erreicht. Dies ist kein offizieller Statuscode, wird aber weiterhin häufig verwendet. |
| 510 | Die für den Zugriff auf die Ressource erforderliche Richtlinie wird nicht erfüllt. (RFC 2774) |
Dieses Werkzeug gehört zur Kategorie „Nachtabellen“.
Eingaben werden möglichst lokal im Browser verarbeitet und nicht gespeichert.
Einige Abfragen bieten einen JSON-Endpunkt; die Liste steht unter Netzwerk-Werkzeuge → API-Referenz.
Spezifikationen entwickeln sich weiter. Hier stehen die gängigen Einträge mit Stand der Aktualisierung — Fehler bitte melden.
Wir behalten die häufig genutzten Einträge, damit die Seite leicht bleibt und schnell lädt.