HTTP/Statuscode

Aus Foxwiki

topic - Kurzbeschreibung

Beschreibung

Jede HTTP-Anfrage wird vom Server mit einem HTTP-Statuscode beantwortet

  • ob die Anfrage erfolgreich bearbeitet wurde
  • teilt dem Client/Browser im Fehlerfall mit, wo (zum Beispiel Umleitung) beziehungsweise wie (zum Beispiel mit Authentifizierung) er die gewünschten Informationen (wenn möglich) erhalten kann

Ein HTTP-Statuscode wird von einem Server auf jede HTTP-Anfrage als Antwort geliefert. Auf der anfragenden Seite steht dabei ein Client wie beispielsweise ein Webbrowser. Der Server teilt durch den HTTP-Statuscode dem Client mit, ob die Anfrage erfolgreich bearbeitet wurde. Im Fehlerfall gibt der Statuscode Auskunft darüber, wo (beispielsweise über eine Umleitung) oder wie (zum Beispiel mit Authentifizierung) er die gewünschten Informationen erhalten kann. Am bekanntesten sind dabei die Codes 404: „Nicht gefunden“, 403: „Fehlende Zugriffsberechtigung“ und 400: „Fehlerhafte Anfrage“.

Beispiel einer Webseite, die von einem Webserver zusätzlich zum 404 Statuscode gesendet wurde.

Die erste Ziffer eines Statuscodes stellt die Statusklasse dar. Sie sind in RFC 7231 (ersetzt RFC 2616), sowie RFC 2518, RFC 2817, RFC 2295, RFC 2774 und RFC 4918 spezifiziert. Einige gehören zum Distributed Authoring (WebDAV).

Neben den in RFC standardisierten Statuscodes verwenden manche Softwarehersteller auch proprietäre Codes für eigens definierte Status- und Fehlermeldungen. Andere Software kann dem Benutzer diese Codes nur als allgemeinen unbekannten Fehler anzeigen; nicht aber eine Übersetzung und Hinweise zum weiteren Vorgehen. Teilweise können die Server den Begleitumständen der Anfrage bereits entnehmen, dass es sich um die zugehörige Spezialsoftware handelt, und geben nur dann die proprietären Codes zurück. In diesem Artikel sind einige proprietäre Codes aufgeführt und entsprechend gekennzeichnet.

Codes  Klasse Beschreibung
1xx Informationen Die Bearbeitung der Anfrage dauert trotz der Rückmeldung noch an
  • Eine solche Zwischenantwort ist manchmal notwendig, da viele Clients nach einer bestimmten Zeitspanne (Zeitüberschreitung) automatisch annehmen, dass ein Fehler bei der Übertragung oder Verarbeitung der Anfrage aufgetreten ist, und mit einer Fehlermeldung abbrechen
2xx Erfolg Die Anfrage wurde bearbeitet und die Antwort wird an den Anfragesteller zurückgesendet
3xx Umleitung Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich
  • Das ist etwa der Fall, wenn eine Webseite vom Betreiber umgestaltet wurde, sodass sich eine gewünschte Datei nun an einem anderen Platz befindet
  • Mit der Antwort des Servers erfährt der Client im Location-Header, wo sich die Datei jetzt befindet
4xx Client-Fehler Bei der Bearbeitung der Anfrage ist ein Fehler aufgetreten, der im Verantwortungsbereich des Clients liegt
  • Ein 404 tritt etwa ein, wenn ein Dokument angefragt wurde, das auf dem Server nicht existiert
  • Ein 403 weist den Client darauf hin, dass es ihm nicht erlaubt ist, das jeweilige Dokument abzurufen
  • Es kann sich zum Beispiel um ein vertrauliches oder nur per HTTPS zugängliches Dokument handeln
5xx Server-Fehler Es ist ein Fehler aufgetreten, dessen Ursache beim Server liegt
  • Zum Beispiel bedeutet 501, dass der Server nicht über die erforderlichen Funktionen (das heißt etwa Programme oder andere Dateien) verfügt, um die Anfrage zu bearbeiten
9xx Proprietäre Fehler

Zusätzlich zum Statuscode enthält der Header der Server-Antwort eine Beschreibung des Fehlers in englischsprachigem Klartext

Mit Fehler 404 kommen Web-Nutzer am häufigsten in Berührung

Zum Beispiel ist ein Fehler 404 an folgendem Header zu erkennen: 

HTTP/1.1 404 Not Found
…

HTTP-Statuscodes

1xx – Informationen

Die Bearbeitung der Anfrage dauert noch an.

Code Nachricht Bedeutung
100 Vorlage:Lang Die laufende Anfrage an den Server wurde noch nicht zurückgewiesen. (Wird im Zusammenhang mit dem „Expect 100-continue“-Header-Feld verwendet.[1]) Der Client kann nun mit der potentiell sehr großen Anfrage fortfahren.
101 Vorlage:Lang Wird verwendet, wenn der Server eine Anfrage mit gesetztem „Upgrade“-Header-Feld empfangen hat und mit dem Wechsel zu einem anderen Protokoll einverstanden ist. Anwendung findet dieser Status-Code beispielsweise im Wechsel von HTTP zu WebSocket.
102 Vorlage:Lang Wird verwendet, um ein Timeout zu vermeiden, während der Server eine zeitintensive Anfrage bearbeitet.[2] Dies ist eine Interim-Antwort, auf die auf derselben Verbindung ohne weitere Client-Anfrage eine endgültige Antwort folgen muss.
103 Vorlage:Lang Wird zusammen mit dem „Link“ Header verwendet, um das Vorladen von Ressourcen zu ermöglichen, während der Server die finale Antwort noch vorbereitet.[3]

2xx – Erfolgreiche Operation

Die Anfrage war erfolgreich, die Antwort kann verwertet werden.

Code Nachricht Bedeutung
200 Vorlage:Lang Die Anfrage wurde erfolgreich bearbeitet und das Ergebnis der Anfrage wird in der Antwort übertragen.
201 Vorlage:Lang Die Anfrage wurde erfolgreich bearbeitet. Die angeforderte Ressource wurde vor dem Senden der Antwort erstellt. Das „Location“-Header-Feld enthält eventuell die Adresse der erstellten Ressource.
202 Vorlage:Lang Die Anfrage wurde akzeptiert, wird aber zu einem späteren Zeitpunkt ausgeführt. Das Gelingen der Anfrage kann nicht garantiert werden.
203 Vorlage:Lang Der Server agiert als „Transforming Proxy“, erhielt eine 200 OK Antwort von der Quelle und antwortet mit einem veränderten Dokument der Quelle.[4][5]
204 Vorlage:Lang Die Anfrage wurde erfolgreich durchgeführt, die Antwort enthält jedoch bewusst keine Daten.
205 Vorlage:Lang Die Anfrage wurde erfolgreich durchgeführt; der Client soll das Dokument neu aufbauen und Formulareingaben zurücksetzen.
206 Vorlage:Lang Der angeforderte Teil wurde erfolgreich übertragen (wird im Zusammenhang mit einem „Content-Range“-Header-Feld oder dem Content-Type multipart/byteranges verwendet). Kann einen Client über Teil-Downloads informieren (wird zum Beispiel von Wget genutzt, um den Downloadfortschritt zu überwachen oder einen Download in mehrere Streams aufzuteilen).
207 Vorlage:Lang WebDAV RFC 4918 – Die Antwort enthält ein in WebDAV spezifiziertes XML-Dokument, das mehrere Statuscodes zu unabhängig voneinander durchgeführten Operationen enthält.
208 Vorlage:Lang WebDAV RFC 5842 – Die Mitglieder einer WebDAV-Bindung wurden bereits zuvor aufgezählt und sind in dieser Anfrage nicht mehr vorhanden.
226 Vorlage:Lang RFC 3229 – Der Server hat eine GET-Anforderung für die Ressource erfüllt, die Antwort ist eine Darstellung des Ergebnisses von einer oder mehrerer Instanz-Manipulationen, bezogen auf die aktuelle Instanz.

3xx – Umleitung

Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich.

Code Nachricht Bedeutung
300 Vorlage:Lang Die angeforderte Ressource steht in verschiedenen Arten zur Verfügung. Die Antwort enthält eine Liste der verfügbaren Arten. Das „Location“-Header-Feld enthält eventuell die Adresse der vom Server bevorzugten Repräsentation.
301 Vorlage:Lang Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit (auch Redirect genannt). Die alte Adresse ist nicht länger gültig.
302 Vorlage:Lang (Vorlage:Lang) Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit.[6] Die alte Adresse bleibt gültig. Die Browser folgen meist mit einem GET, auch wenn der ursprüngliche Request ein POST war. Wird in HTTP/1.1 je nach Anwendungsfall durch die Statuscodes 303 oder 307 ersetzt. 302-Weiterleitung ist aufgrund eines Suchmaschinen-Fehlers, des URL-Hijackings, in Kritik geraten.
303 Vorlage:Lang Die Antwort auf die durchgeführte Anfrage lässt sich unter der im „Location“-Header-Feld angegebenen Adresse beziehen. Der Browser soll mit einem GET folgen, auch wenn der ursprüngliche Request ein POST war.
304 Vorlage:Lang Der Inhalt der angeforderten Ressource hat sich seit der letzten Abfrage des Clients nicht verändert und wird deshalb nicht übertragen. Zu den Einzelheiten siehe Browser-Cache-Versionsvergleich.
305 Vorlage:Lang Die angeforderte Ressource ist nur über einen Proxy erreichbar. Das „Location“-Header-Feld enthält die Adresse des Proxys.
306 Vorlage:Lang 306 wird nicht mehr verwendet, ist aber reserviert. Es wurde für „Switch Proxy“ verwendet.
307 Vorlage:Lang Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig. Der Browser soll mit derselben Methode folgen wie beim ursprünglichen Request (d. h. einem POST folgt ein POST). Dies ist der wesentliche Unterschied zu 302/303.
308 Vorlage:Lang Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit, die alte Adresse ist nicht länger gültig. Der Browser soll mit derselben Methode folgen wie beim ursprünglichen Request (d. h. einem POST folgt ein POST). Dies ist der wesentliche Unterschied zu 301.[7]

4xx – Client-Fehler

Die Ursache des Scheiterns der Anfrage liegt (eher) im Verantwortungsbereich des Clients.

Code Nachricht Bedeutung
400 Vorlage:Lang Die Anfrage-Nachricht war fehlerhaft aufgebaut.
401 Vorlage:Lang Die Anfrage kann nicht ohne gültige Authentifizierung durchgeführt werden. Wie die Authentifizierung durchgeführt werden soll, wird im „WWW-Authenticate“-Header-Feld der Antwort übermittelt.
402 Vorlage:Lang Bezahlung benötigt. Dieser Status ist für zukünftige HTTP-Protokolle reserviert.
403 Vorlage:Lang Die Anfrage wurde mangels Berechtigung des Clients nicht durchgeführt, bspw. weil der authentifizierte Benutzer nicht berechtigt ist oder eine als HTTPS konfigurierte URL nur mit HTTP aufgerufen wurde.
404 Vorlage:Lang Die angeforderte Ressource wurde nicht gefunden. Dieser Statuscode kann ebenfalls verwendet werden, um eine Anfrage ohne näheren Grund abzuweisen. Links, die auf solche Fehlerseiten verweisen, werden auch als Tote Links bezeichnet. „404“ gilt zudem als verbreitetes Meme.
405 Vorlage:Lang Die Anfrage darf nur mit anderen HTTP-Methoden (zum Beispiel GET statt POST) gestellt werden. Gültige Methoden für die betreffende Ressource werden im „Allow“-Header-Feld der Antwort übermittelt.
406 Vorlage:Lang Die angeforderte Ressource steht nicht in der gewünschten Form zur Verfügung. Gültige „Content-Type“-Werte können in der Antwort übermittelt werden.
407 Vorlage:Lang Analog zum Statuscode 401 ist hier zunächst eine Authentifizierung des Clients gegenüber dem verwendeten Proxy erforderlich. Wie die Authentifizierung durchgeführt werden soll, wird im „Proxy-Authenticate“-Header-Feld der Antwort übermittelt.
408 Vorlage:Lang Innerhalb der vom Server erlaubten Zeitspanne wurde keine vollständige Anfrage des Clients empfangen.
409 Vorlage:Lang Die Anfrage wurde unter falschen Annahmen gestellt. Im Falle einer PUT-Anfrage kann dies zum Beispiel auf eine zwischenzeitliche Veränderung der Ressource durch Dritte zurückgehen.
410 Vorlage:Lang Die angeforderte Ressource wird nicht länger bereitgestellt und wurde dauerhaft entfernt.
411 Vorlage:Lang Die Anfrage kann ohne ein „Content-Length“-Header-Feld nicht bearbeitet werden.
412 Vorlage:Lang Eine in der Anfrage übertragene Voraussetzung, zum Beispiel in Form eines „If-Match“-Header-Felds, traf nicht zu.
413 Vorlage:Lang Die gestellte Anfrage war zu groß, um vom Server bearbeitet werden zu können. Ein „Retry-After“-Header-Feld in der Antwort kann den Client darauf hinweisen, dass die Anfrage eventuell zu einem späteren Zeitpunkt bearbeitet werden könnte.
414 Vorlage:Lang Die URL der Anfrage war zu lang. Ursache ist oft eine Endlosschleife aus Redirects.
415 Vorlage:Lang Der Inhalt der Anfrage wurde mit ungültigem oder nicht erlaubtem Medientyp übermittelt.
416 Vorlage:Lang Der angeforderte Teil einer Ressource war ungültig oder steht auf dem Server nicht zur Verfügung.
417 Vorlage:Lang Verwendet im Zusammenhang mit einem „Expect“-Header-Feld. Das im „Expect“-Header-Feld geforderte Verhalten des Servers kann nicht erfüllt werden.
421 Vorlage:Lang Die Anfrage wurde an einen Server gesendet, der nicht in der Lage ist, eine Antwort zu senden. Eingeführt in HTTP/2.
422 Vorlage:Lang Verwendet, wenn weder die Rückgabe von Statuscode 415 noch 400 gerechtfertigt wäre, eine Verarbeitung der Anfrage jedoch zum Beispiel wegen semantischer Fehler abgelehnt wird.[8]
423 Vorlage:Lang Die angeforderte Ressource ist zurzeit gesperrt.[8]
424 Vorlage:Lang Die Anfrage konnte nicht durchgeführt werden, weil sie das Gelingen einer anderen Anfrage voraussetzt.[8]
425 Vorlage:Lang Der Server bittet den Client die Anfrage erneut zu senden, da die TLS-Verbindung noch nicht vollständig hergestellt wurde.[9] Dies soll einen Replay-Angriff verhindern.
426 Vorlage:Lang Der Server verlangt vom Client, dass er die Anfrage mit einem anderen Protokoll wiederholt.[10] Ein Anwendungsfall ist das Umschalten auf HTTP mit Transport Layer Security.[11]
428 Vorlage:Lang Für die Anfrage waren nicht alle Vorbedingungen erfüllt. Dieser Statuscode soll Probleme durch Race Conditions verhindern, indem eine Manipulation oder Löschen nur erfolgt, wenn der Client dies auf Basis einer aktuellen Ressource anfordert (Beispielsweise durch Mitliefern eines aktuellen ETag-Header).[12]
429 Vorlage:Lang Der Client hat zu viele Anfragen in einem bestimmten Zeitraum gesendet.[12]
431 Vorlage:Lang Die Maximallänge eines Headerfelds oder des Gesamtheaders wurde überschritten.[12]
451 Vorlage:Lang Dieser Statuscode soll darauf hinweisen, dass die angeforderte Ressource aufgrund von gesetzlichen Bestimmungen (Copyrighteinschränkungen, Zensur etc., eventuell beschränkt auf ein bestimmtes Land) nicht verfügbar ist.[13]

Er wurde im Juni 2012 von Google-Mitarbeiter Tim Bray bei der IETF eingereicht[14] und gilt seit dem 17. Dezember 2015 als angenommen.[15] Bray schlug die Nummer 451 in Anspielung auf Ray Bradburys Roman Fahrenheit 451 vor und fügte einen Dank an den Autor an.[16]

Beispiele für weitere, per Juli 2020 nicht in der Hypertext Transfer Protocol (HTTP) Status Code Registry[17] aufgeführte Codes:
418 Vorlage:Lang Dieser Code ist als Aprilscherz der IETF zu verstehen. Innerhalb eines scherzhaften Protokolls zum Kaffeekochen, des Hyper Text Coffee Pot Control Protocols,[18] zeigt er an, dass fälschlicherweise eine Teekanne anstatt einer Kaffeekanne verwendet wurde. Dieser Scherz-Statuscode ist auf einigen Websites zu finden, obwohl er weder Bestandteil von HTTP ist noch in der Status Code Registry[17] definiert ist. Er soll zukünftig als „reserviert“ gelistet werden.[19]
420 Vorlage:Lang In W3C PEP (Working Draft 21. November 1997)[20] wird dieser Code vorgeschlagen, um mitzuteilen, dass eine Bedingung nicht erfüllt wurde.
444 Vorlage:Lang In nginx-Logs verwendet, um anzuzeigen, dass der Server keine Informationen zum Client zurückgesendet und die Verbindung geschlossen hat.
449 Vorlage:Lang Genutzt in Antworten des Microsoft Exchange Servers.[21]
499 Vorlage:Lang Ein nicht standardmäßiger Statuscode, der von nginx für den Fall eingeführt wurde, dass ein Client die Verbindung schließt, während nginx die Anforderung verarbeitet.

5xx – Server-Fehler

Nicht klar von den so genannten Client-Fehlern abzugrenzen. Die Ursache des Scheiterns der Anfrage liegt jedoch eher im Verantwortungsbereich des Servers.

Code Nachricht Bedeutung
500 Vorlage:Lang Dies ist ein „Sammel-Statuscode“ für unerwartete Serverfehler.
501 Vorlage:Lang Die Funktionalität, um die Anfrage zu bearbeiten, wird von diesem Server nicht bereitgestellt. Ursache ist zum Beispiel eine unbekannte oder nicht unterstützte HTTP-Methode.
502 Vorlage:Lang Der Server konnte seine Funktion als Gateway oder Proxy nicht erfüllen, weil er seinerseits eine ungültige Antwort erhalten hat.
503 Vorlage:Lang Der Server steht temporär nicht zur Verfügung, zum Beispiel wegen Überlastung oder Wartungsarbeiten. Ein „Retry-After“-Header-Feld in der Antwort kann den Client auf einen Zeitpunkt hinweisen, zu dem die Anfrage eventuell bearbeitet werden könnte.
504 Vorlage:Lang Der Server konnte seine Funktion als Gateway oder Proxy nicht erfüllen, weil er innerhalb einer festgelegten Zeitspanne keine Antwort von seinerseits benutzten Servern oder Diensten erhalten hat.
505 Vorlage:Lang Die benutzte HTTP-Version (gemeint ist die Zahl vor dem Punkt) wird vom Server nicht unterstützt oder abgelehnt.
506 Vorlage:Lang Die Inhaltsvereinbarung der Anfrage ergibt einen Zirkelbezug.[22]
507 Vorlage:Lang Die Anfrage konnte nicht bearbeitet werden, weil der Speicherplatz des Servers dazu derzeit nicht mehr ausreicht.[8]
508 Vorlage:Lang Die Operation wurde nicht ausgeführt, weil die Ausführung in eine Endlosschleife gelaufen wäre. Definiert in der Binding-Erweiterung für WebDAV gemäß RFC 5842, weil durch Bindings zyklische Pfade zu WebDAV-Ressourcen entstehen können.
509 Vorlage:Lang Die Anfrage wurde verworfen, weil sonst die verfügbare Bandbreite überschritten würde (inoffizielle Erweiterung einiger Server).
510 Vorlage:Lang Die Anfrage enthält nicht alle Informationen, welche die angefragte Server-Extension zwingend erwartet.[23]
511 Vorlage:Lang Der Client muss sich zuerst authentifizieren, um Zugang zum Netzwerk zu erhalten.[12]

9xx – Proprietäre Fehler

Manche Softwarehersteller verwenden den Bereich ab 900 für proprietäre Statuscodes.[24] Dieser Zahlenbereich wurde in den RFC-Dokumenten nie erwähnt und liegt offensichtlich jenseits der standardisierten Codes. Dadurch ist er leicht als Sonderfall erkennbar.

Anhang

Siehe auch

Links

Weblinks
  1. ↑ RFC 2616 – Hypertext Transfer Protocol – HTTP/1.1
  2. ↑ RFC 2518
  3. ↑ RFC 8297
  4. ↑ Roy Fielding, Julian Reschke: 6.3.4 – Semantics and Content. RFC 7231 – Hypertext Transfer Protocol (HTTP/1.1), Juni 2014
  5. ↑ Roy Fielding, Julian Reschke: 5.7.2 – Transformations. RFC 7230 – Message Syntax and Routing, Juni 2014
  6. ↑ RFC 1945
  7. ↑ Julian Reschke: RFC 7538 – The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect), IETF, April 2015.
  8. ↑ 8,0 8,1 8,2 8,3 RFC 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
  9. ↑ RFC 8470
  10. ↑ RFC 7231. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Abschnitt 6.5.15.
  11. ↑ RFC 2817. Upgrading to TLS within HTTP/1.1.
  12. ↑ 12,0 12,1 12,2 12,3 RFC 6585 Additional HTTP Status Codes
  13. ↑ A New HTTP Status Code for Legally-restricted Resources
  14. ↑ tools.ietf.org
  15. ↑ datatracker.ietf.org
  16. ↑ Appendix A
  17. ↑ 17,0 17,1 iana.org
  18. ↑ Error 418 I’m a Teapot. It started in 1998, described in the RFC 2324 of 1998.
  19. ↑ Reserving the 418 HTTP Status Code draft-nottingham-thanks-larry-00
  20. ↑ w3.org W3C PEP (Working Draft 21. November 1997)
  21. ↑ Microsoft Open Specifications Support Team Blog auf MSDN. Abgerufen am 2. Mrz. 2016
  22. ↑ RFC 2295
  23. ↑ RFC 2774
  24. ↑ Beispielsweise liefert Linkedin bei Zugriff via curl den Code 999: curl -kI https://www.linkedin.com/company/linkedin/ (vgl. Stackoverflow)
Abgerufen von „https://wiki.foxtom.de/index.php?title=HTTP/Statuscode&oldid=95961“