
Basic-Auth-Generator
Basic-Authentication-Daten für HTTP-Anfragen erzeugen.
Referenz für HTTP-Statuscodes: Bedeutung, Beispiele und Best Practices.
Der Server hat den Anfang der Anfrage erhalten und der Client soll mit dem Senden des Anfragekörpers fortfahren.
Der Server akzeptiert den vom Client angeforderten Protokollwechsel.
Der Server verarbeitet die Anfrage, es liegt aber noch keine Antwort vor (WebDAV).
Der Server sendet vorab einige Antwort-Header, bevor die endgültige HTTP-Nachricht folgt.
Standardantwort für erfolgreiche HTTP-Anfragen.
Die Anfrage war erfolgreich und führte zur Erstellung einer neuen Ressource.
Die Anfrage wurde zur Verarbeitung angenommen, ist aber noch nicht abgeschlossen.
Der Server liefert eine modifizierte Version der ursprünglich vom Origin-Server empfangenen 200-Antwort.
Die Anfrage wurde erfolgreich verarbeitet, die Antwort enthält aber keinen Inhalt.
Wie 204, zusätzlich soll der Client das anfragende Formular zurücksetzen.
Der Server liefert aufgrund eines Range-Headers nur einen Teil der angeforderten Ressource.
Der Antwortkörper enthält eine XML-Nachricht mit mehreren unabhängigen Statuscodes (WebDAV).
Vermeidet die wiederholte Aufzählung interner Mitglieder mehrerer Bindungen in einem DAV-propstat-Element.
Die Antwort ist das Ergebnis einer oder mehrerer Instanzmanipulationen, die auf die aktuelle Instanz angewendet wurden.
Für die Anfrage gibt es mehrere mögliche Antworten; der Client soll eine davon auswählen.
Die angeforderte Ressource wurde dauerhaft unter eine neue URL verschoben.
Die Ressource befindet sich vorübergehend unter einer anderen URL.
Die Antwort ist unter einer anderen URI mittels GET-Methode zu finden.
Die Ressource wurde seit der letzten Anfrage nicht verändert; der Client kann die zwischengespeicherte Version nutzen.
Die angeforderte Ressource ist nur über den in der Antwort angegebenen Proxy erreichbar (veraltet).
Nicht mehr verwendet; ursprünglich für zukünftige Anfragen über einen anderen Proxy reserviert.
Die Ressource befindet sich vorübergehend unter einer anderen URI, die Methode bleibt dabei unverändert.
Die Ressource befindet sich dauerhaft unter einer anderen URI, die Methode bleibt dabei unverändert.
Der Server kann die Anfrage aufgrund fehlerhafter Syntax nicht verarbeiten.
Authentifizierung ist erforderlich, fehlt aber oder ist fehlgeschlagen.
Für zukünftige Verwendung reserviert, ursprünglich für digitale Bezahlsysteme vorgesehen.
Der Client hat keine Zugriffsberechtigung auf den angeforderten Inhalt.
Der Server kann die angeforderte Ressource nicht finden.
Die verwendete Anfragemethode wird von der Zielressource nicht unterstützt.
Der Server kann keine Antwort erzeugen, die den im Accept-Header geforderten Kriterien entspricht.
Der Client muss sich zuerst gegenüber dem Proxy authentifizieren.
Der Server hat beim Warten auf die vollständige Anfrage die Zeitgrenze überschritten.
Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource.
Die Ressource wurde absichtlich und dauerhaft entfernt und ist nicht mehr verfügbar.
Die Anfrage hat den erforderlichen Content-Length-Header nicht angegeben.
Eine vom Client gesetzte Vorbedingung wird vom Server nicht erfüllt.
Die Anfrage ist größer, als der Server bereit oder in der Lage ist zu verarbeiten.
Der angegebene URI ist zu lang, um vom Server verarbeitet zu werden.
Der Medientyp der Anfrage wird vom Server oder der Ressource nicht unterstützt.
Der angeforderte Teilbereich der Datei kann vom Server nicht bereitgestellt werden.
Der Server kann die im Expect-Header geforderten Bedingungen nicht erfüllen.
Der Server weigert sich, Kaffee zu kochen, da er eine Teekanne ist (Aprilscherz-RFC von 1998).
Die Anfrage wurde an einen Server geleitet, der keine passende Antwort erzeugen kann.
Der Inhaltstyp wird verstanden, die enthaltenen Anweisungen konnten aber nicht verarbeitet werden.
Die angeforderte Ressource ist gesperrt.
Die Anfrage ist fehlgeschlagen, weil eine vorherige, abhängige Anfrage fehlgeschlagen ist.
Der Server verarbeitet die Anfrage nicht, um das Risiko einer Replay-Attacke zu vermeiden.
Der Client soll auf ein anderes, im Upgrade-Header angegebenes Protokoll wechseln.
Der Origin-Server verlangt, dass die Anfrage bedingt gestellt wird.
Der Client hat in kurzer Zeit zu viele Anfragen gesendet (Rate-Limiting).
Einzelne oder alle Header-Felder der Anfrage sind zu groß für den Server.
Der Zugriff auf die Ressource ist aus rechtlichen Gründen gesperrt, etwa durch behördliche Anordnung.
Der Server ist auf eine unerwartete Situation gestoßen, die er nicht genauer beschreiben kann.
Der Server unterstützt die angeforderte Methode nicht und kann sie nicht verarbeiten.
Der Server hat als Gateway oder Proxy eine ungültige Antwort vom vorgelagerten Server erhalten.
Der Server ist derzeit nicht in der Lage, die Anfrage zu bearbeiten, oft wegen Wartung oder Überlastung.
Der Server hat als Gateway oder Proxy keine rechtzeitige Antwort vom vorgelagerten Server erhalten.
Die in der Anfrage verwendete HTTP-Version wird vom Server nicht unterstützt.
Interner Konfigurationsfehler: Die Inhaltsverhandlung für die Anfrage führt zu einer Endlosreferenz.
Der Server kann die zur Erfüllung der Anfrage nötige Darstellung nicht speichern.
Der Server hat bei der Verarbeitung der Anfrage eine Endlosschleife erkannt.
Für die Anfrage sind weitere Erweiterungen nötig, damit der Server sie erfüllen kann.
Der Client muss sich authentifizieren, um Zugang zum Netzwerk zu erhalten.
Statuscodes sind in fünf Gruppen unterteilt: 1xx Information, 2xx Erfolg, 3xx Umleitung, 4xx Client-Fehler und 5xx Server-Fehler.
Die Codes sind in RFC 7231 und ergänzenden RFCs (z. B. WebDAV, RFC 6585) standardisiert und werden von allen HTTP-Clients einheitlich interpretiert.
Codes wie 301, 404 und 410 beeinflussen, wie Suchmaschinen URLs behandeln – wichtig für Weiterleitungen und die Indexierung.
Ein korrekter Statuscode macht APIs vorhersehbar und erleichtert Fehlerbehandlung sowie Debugging auf Client-Seite.
HTTP-Statuscodes sind dreistellige Zahlen, die ein Server in jeder Antwort auf eine HTTP-Anfrage zurückgibt. Sie zeigen an, ob eine Anfrage erfolgreich war, ob eine Umleitung nötig ist, ob der Client einen Fehler gemacht hat oder ob auf dem Server ein Problem aufgetreten ist. Die erste Ziffer bestimmt die Kategorie der Antwort.
Für Entwickler und Betreiber von APIs sind Statuscodes essenziell für Debugging, Monitoring und korrektes Fehlerhandling im Frontend. Suchmaschinen nutzen bestimmte Codes (z. B. 301, 404, 410), um Umleitungen und entfernte Inhalte im Index korrekt zu behandeln.
Ein HTTP-Statuscode ist eine dreistellige Zahl, die ein Server als Teil jeder HTTP-Antwort sendet. Sie gibt an, ob eine Anfrage erfolgreich war, umgeleitet wurde oder ein Fehler aufgetreten ist.
Die erste Ziffer legt die Kategorie fest: 1 = Information, 2 = Erfolg, 3 = Umleitung, 4 = Client-Fehler, 5 = Server-Fehler.
404 (Not Found) bedeutet, dass die Ressource nicht gefunden wurde, möglicherweise nur vorübergehend. 410 (Gone) signalisiert, dass die Ressource bewusst und dauerhaft entfernt wurde.
301 (Moved Permanently) wird für dauerhafte Umleitungen genutzt und überträgt SEO-Wert auf die neue URL. 302 (Found) signalisiert eine nur vorübergehende Umleitung.
Ein 500 (Internal Server Error) bedeutet, dass der Server auf eine unerwartete Situation gestoßen ist, die er nicht genauer spezifizieren kann. Die Ursache liegt serverseitig, nicht bei der Anfrage selbst.

Basic-Authentication-Daten für HTTP-Anfragen erzeugen.

Infos zu Ihrem Gerät: Betriebssystem, Browser und mehr.

Informationen zu Tastatur-Keycodes.

Hypotenuse oder Kathete, rechtwinkliges Dreieck prüfen. Fläche und Umfang.