HTTP-Antworten sind ein wichtiger Teil der Web-Kommunikation, da sie es Servern ermöglichen, auf Client-Anfragen mit den angeforderten Daten, Statusinformationen und anderen wichtigen Details zu antworten. Dieser Artikel erklärt die Struktur und Bestandteile einer HTTP-Antwort, einschließlich der Statuszeile, Header und Body. Wir betrachten die verschiedenen Gruppen von HTTP-Statuscodes und ihre Bedeutungen anhand praktischer Beispiele. Außerdem besprechen wir bewährte Methoden für den Umgang mit HTTP-Antworten in der Webentwicklung, sowohl auf Client- als auch auf Server-Seite, um eine reibungslose Kommunikation zu gewährleisten.
Die wichtigsten Punkte
- Eine HTTP-Antwort ist die Nachricht, die ein Webserver nach Empfang und Verarbeitung einer HTTP-Anfrage an einen Client zurücksendet.
- Zu den Hauptbestandteilen einer HTTP-Antwort gehören die Statuszeile, Header und ein optionaler Body mit dem angeforderten Inhalt.
- HTTP-Statuscodes werden in informative Antworten (1xx), erfolgreiche Antworten (2xx), Weiterleitungsnachrichten (3xx), Client-Fehlerantworten (4xx) und Server-Fehlerantworten (5xx) unterteilt.
- Auf der Client-Seite ist es wichtig, Statuscodes zu prüfen, Antwortdaten basierend auf dem Content-Type-Header zu verarbeiten und Weiterleitungen sowie Fehler angemessen zu behandeln.
- Auf der Server-Seite sind das Setzen der richtigen Statuscodes und Header, das Bereitstellen klarer Fehlermeldungen sowie die Implementierung einer ordnungsgemäßen Fehlerbehandlung und Protokollierung für eine gute Webentwicklung unerlässlich.
Was ist eine HTTP-Antwort?
Eine HTTP-Antwort ist die Nachricht, die ein Webserver nach Empfang und Verarbeitung einer HTTP-Anfrage an einen Client zurücksendet. Sie liefert das Ergebnis der Client-Anfrage, sei es ein Erfolg, ein Fehler oder etwas dazwischen. Die Antwort enthält Statusinformationen über die Anfrage und kann auch Inhalt im Body haben, wie zum Beispiel die angeforderte Ressource (eine Webseite, ein Bild, JSON-Daten usw.) oder eine Fehlermeldung.
HTTP-Antworten sind notwendig, damit ein Client verstehen kann, ob seine Anfrage erfolgreich war oder nicht und was das Ergebnis dieser Anfrage war. Webbrowser verwenden HTTP-Antworten, um zu wissen, welchen Inhalt sie Benutzern anzeigen sollen. APIs verwenden HTTP-Antworten, um das Ergebnis von Operationen anzuzeigen und Daten zurückzusenden. Die Struktur und der Inhalt der HTTP-Antwort bestimmen, wie der Client weitermacht.
Bestandteile einer HTTP-Antwort
Eine HTTP-Antwort besteht aus mehreren wichtigen Komponenten:
- Statuszeile: Die erste Zeile der Antwort, die die HTTP-Version, einen Statuscode und eine Statusmeldung enthält.
- Header: Schlüssel-Wert-Paare, die zusätzliche Informationen über die Antwort liefern, wie zum Beispiel den Content-Type, die Inhaltslänge, Caching-Anweisungen und mehr.
- Body (optional): Der eigentliche Inhalt der Antwort, wie HTML, JSON, ein Bild usw.
Hier ist ein Beispiel einer einfachen HTTP-Antwort:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<!DOCTYPE html>
<html>
<head>
<title>Beispielseite</title>
</head>
<body>
<h1>Hallo Welt!</h1>
<p>Dies ist eine Beispielseite.</p>
</body>
</html>
Beispiele aus der Praxis
Web-Browsing: Wenn Sie eine URL in Ihren Webbrowser eingeben, sendet dieser eine HTTP-Anfrage an den Server. Der Server antwortet dann mit einer HTTP-Antwort, die den HTML-Inhalt der Webseite enthält. Ihr Browser verwendet diese Antwort, um die Seite darzustellen.
API-Interaktion: Wenn eine Anwendung eine Anfrage an einen API-Endpunkt stellt, antwortet der API-Server mit einer HTTP-Antwort. Diese Antwort enthält oft JSON-Daten, die die Anwendung verwenden kann. Zum Beispiel könnte eine Wetter-App eine Anfrage an eine Wetter-API stellen und aktuelle Wetterdaten in der Antwort erhalten.
Datei-Download: Wenn Sie auf einen Link zum Herunterladen einer Datei klicken, sendet Ihr Browser eine HTTP-Anfrage an den Server. Der Server antwortet mit einer HTTP-Antwort, die die Dateidaten im Body und Header enthält, die den Dateityp und die Größe angeben.
Bestandteile einer HTTP-Antwort
Eine HTTP-Antwort hat mehrere wichtige Teile, die Informationen über das Ergebnis der Anfrage liefern und die angeforderten Daten übermitteln.
Statuszeile
Die Statuszeile ist die erste Zeile der HTTP-Antwort. Sie enthält:
- HTTP-Version: Zeigt die verwendete HTTP-Protokollversion an, wie HTTP/1.1 oder HTTP/2.
- Statuscode: Eine dreistellige Zahl, die das Anfrageergebnis anzeigt, wie 200 für Erfolg, 404 für „nicht gefunden" oder 500 für einen Server-Fehler.
- Statustext: Eine kurze Beschreibung des Statuscodes, wie „OK" für 200, „Not Found" für 404 oder „Internal Server Error" für 500.
Hier sind einige häufige HTTP-Statuscodes und ihre Bedeutungen:
| Statuscode | Statustext | Bedeutung |
|---|---|---|
| 200 | OK | Die Anfrage war erfolgreich und der Antwort-Body enthält die Daten. |
| 201 | Created | Die Anfrage war erfolgreich und eine neue Ressource wurde erstellt. |
| 301 | Moved Permanently | Die angeforderte Ressource wurde dauerhaft zu einer neuen URL verschoben. |
| 400 | Bad Request | Der Server konnte die Anfrage aufgrund ungültiger Syntax nicht verstehen. |
| 401 | Unauthorized | Die Anfrage erfordert eine Benutzerauthentifizierung. |
| 404 | Not Found | Der Server konnte die angeforderte Ressource nicht finden. |
| 500 | Internal Server Error | Der Server ist auf einen unerwarteten Fehler gestoßen. |
Der HTTP-Statuscode ist Teil der Antwortnachricht. Er definiert die Klasse der Antwort und spielt eine kategorisierende Rolle. Die erste Ziffer des Statuscodes gibt den Typ der Antwort an:
- 1xx: Informative Antwort
- 2xx: Erfolg
- 3xx: Weiterleitung
- 4xx: Client-Fehler
- 5xx: Server-Fehler
HTTP-Statuscodes sind erweiterbar, aber HTTP-Anwendungen müssen nicht die Bedeutung aller registrierten Statuscodes verstehen. Zusätzliche Informationen über die Antwort finden sich in den Antwort-Header-Feldern.
Antwort-Header
Nach der Statuszeile folgen die Antwort-Header. Dies sind Schlüssel-Wert-Paare, die mehr Details über die Antwort geben. Einige häufige Header sind:
- Server: Der Servertyp, der die Antwort generiert hat, wie „Apache/2.4.41 (Ubuntu)".
- Content-Type: Der MIME-Typ der Daten im Antwort-Body, wie „text/html" für HTML oder „application/json" für JSON.
- Content-Length: Die Größe des Antwort-Body in Bytes.
- Cache-Control: Anweisungen für Caching-Mechanismen, die angeben, ob die Antwort gecacht werden kann, wie lange usw. Zum Beispiel bedeutet „max-age=3600", dass die Antwort eine Stunde lang gecacht werden kann.
- Set-Cookie: Sendet Cookies vom Server an den Client, wie „session_id=abc123; Expires=Wed, 21 Jun 2023 07:28:00 GMT".
Leerzeile
Nach den Headern folgt eine Leerzeile. Diese leere Zeile signalisiert das Ende des Header-Bereichs der Antwort.
Antwort-Body
Nach der Leerzeile kommt der Antwort-Body. Dieser enthält die eigentlichen Daten, die angefordert wurden, wie:
Eine HTML-Datei für eine Webseite:
<!DOCTYPE html> <html> <head> <title>Beispielseite</title> </head> <body> <h1>Willkommen auf der Beispielseite</h1> <p>Dies ist ein Beispiel eines HTML-Antwort-Body.</p> </body> </html>JSON-Daten für eine API-Antwort:
{ "name": "Max Mustermann", "age": 30, "city": "Berlin" }Ein Bild, Video oder eine andere Mediendatei.
Eine Datei zum Download, wie ein PDF oder ZIP-Archiv.
Wenn die Antwort einen Fehler anzeigt, wie einen 404- oder 500-Statuscode, könnte der Body eine Fehlermeldung enthalten, die mehr Details über das Problem liefert, wie zum Beispiel:
<!DOCTYPE html>
<html>
<head>
<title>404 Nicht gefunden</title>
</head>
<body>
<h1>404 Nicht gefunden</h1>
<p>Die angeforderte Ressource konnte auf diesem Server nicht gefunden werden.</p>
</body>
</html>
Der Antwort-Body ist optional. Bei einigen Anfragen, wie einer HEAD-Anfrage oder einer 204 „No Content"-Antwort, gibt es keinen Body.
HTTP-Antwort-Statuscode-Kategorien
HTTP-Antwort-Statuscodes sind basierend auf ihrer ersten Ziffer in fünf Kategorien unterteilt. Jede Kategorie repräsentiert eine andere Klasse von Antworten.
Informative Antworten (100-199)
Statuscodes im Bereich 100-199 bedeuten, dass der Server die Anfrage erhalten hat und sie verarbeitet. Diese Codes sind Antworten. Einige häufige informative Statuscodes sind:
| Statuscode | Beschreibung |
|---|---|
100 Continue |
Der Server hat die Anfrage-Header erhalten und der Client sollte den Anfrage-Body senden. |
102 Processing |
Der Server hat die Anfrage erhalten und verarbeitet sie, aber noch ist keine Antwort verfügbar. |
Beispielszenario:
- Ein Client sendet eine POST-Anfrage mit einer großen Nutzlast. Der Server antwortet mit einem
100 Continue-Statuscode, um dem Client mitzuteilen, den Anfrage-Body zu senden.
Erfolgreiche Antworten (200-299)
Statuscodes im Bereich 200-299 bedeuten, dass der Server die Anfrage empfangen, verstanden und akzeptiert hat. Einige häufige erfolgreiche Statuscodes sind:
| Statuscode | Beschreibung |
|---|---|
200 OK |
Die Anfrage war erfolgreich und der Antwort-Body enthält die angeforderten Daten. |
201 Created |
Die Anfrage war erfolgreich und eine neue Ressource wurde erstellt. Dies wird häufig als Antwort auf eine POST-Anfrage verwendet. |
204 No Content |
Der Server hat die Anfrage erfüllt, muss aber keinen Inhalt zurückgeben. |
Beispielszenarien:
- Ein Client fordert eine Webseite mit einer GET-Anfrage an. Der Server antwortet mit einem
200 OK-Statuscode und gibt den HTML-Inhalt zurück. - Ein Client sendet ein Formular ab, um eine neue Ressource mit einer POST-Anfrage zu erstellen. Der Server erstellt die Ressource und antwortet mit einem
201 Created-Statuscode. - Ein Client sendet eine DELETE-Anfrage, um eine Ressource zu entfernen. Der Server löscht die Ressource und antwortet mit einem
204 No Content-Statuscode.
Weiterleitungsnachrichten (300-399)
Statuscodes im Bereich 300-399 bedeuten, dass der Client weitere Aktionen ausführen muss, um die Anfrage abzuschließen. Die Aktion kann vom User Agent ohne Benutzerinteraktion durchgeführt werden. Einige häufige Weiterleitungs-Statuscodes sind:
| Statuscode | Beschreibung |
|---|---|
301 Moved Permanently |
Der angeforderten Ressource wurde eine neue permanente URI zugewiesen und zukünftige Verweise sollten eine der zurückgegebenen URIs verwenden. |
302 Found |
Die angeforderte Ressource befindet sich unter einer anderen URI. Der Client sollte die Request-URI für zukünftige Anfragen weiterhin verwenden. |
304 Not Modified |
Die Ressource wurde seit der in den Anfrage-Headern angegebenen Version nicht geändert, daher kann der Client die gecachte Version weiterhin verwenden. |
Beispielszenarien:
- Ein Client fordert eine Ressource an, die dauerhaft zu einer neuen URL verschoben wurde. Der Server antwortet mit einem
301 Moved Permanently-Statuscode und fügt die neue URL imLocation-Header hinzu. - Ein Client fordert eine Ressource an, die sich unter einer anderen URL befindet. Der Server antwortet mit einem
302 Found-Statuscode und fügt die temporäre URL imLocation-Header hinzu. - Ein Client sendet eine bedingte GET-Anfrage mit
If-Modified-Since-Header. Wenn die Ressource seit dem angegebenen Datum nicht geändert wurde, antwortet der Server mit einem304 Not Modified-Statuscode.
Client-Fehlerantworten (400-499)
Statuscodes im Bereich 400-499 bedeuten, dass der Client offenbar einen Fehler gemacht hat. Außer bei der Antwort auf eine HEAD-Anfrage sollte der Server eine Entität einschließen, die den Fehler erklärt. Einige häufige Client-Fehler-Statuscodes sind:
| Statuscode | Beschreibung |
|---|---|
400 Bad Request |
Der Server konnte die Anfrage aufgrund falscher Syntax nicht verstehen. |
401 Unauthorized |
Die Anfrage erfordert eine Benutzerauthentifizierung. |
404 Not Found |
Der Server hat nichts gefunden, das mit der Request-URI übereinstimmt. |
Beispielszenarien:
- Ein Client sendet eine Anfrage mit ungültigen oder fehlenden Parametern. Der Server antwortet mit einem
400 Bad Request-Statuscode und fügt eine Fehlermeldung im Antwort-Body hinzu. - Ein Client versucht, auf eine geschützte Ressource zuzugreifen, ohne gültige Authentifizierung bereitzustellen. Der Server antwortet mit einem
401 Unauthorized-Statuscode und fordert den Client zur Authentifizierung auf. - Ein Client fordert eine Ressource an, die auf dem Server nicht existiert. Der Server antwortet mit einem
404 Not Found-Statuscode.
Server-Fehlerantworten (500-599)
Statuscodes im Bereich 500-599 bedeuten, dass der Server weiß, dass er einen Fehler gemacht hat oder die Anfrage nicht ausführen kann. Außer bei der Antwort auf eine HEAD-Anfrage sollte der Server eine Entität einschließen, die den Fehler erklärt und ob es sich um einen temporären oder permanenten Zustand handelt. Einige häufige Server-Fehler-Statuscodes sind:
| Statuscode | Beschreibung |
|---|---|
500 Internal Server Error |
Der Server ist auf einen unerwarteten Zustand gestoßen, der ihn daran hinderte, die Anfrage zu erfüllen. |
503 Service Unavailable |
Der Server kann die Anfrage derzeit aufgrund einer temporären Überlastung oder Wartung des Servers nicht bearbeiten. |
504 Gateway Timeout |
Der Server hat in seiner Funktion als Gateway oder Proxy keine rechtzeitige Antwort vom Upstream-Server erhalten, auf den er zugreifen musste, um die Anfrage abzuschließen. |
Beispielszenarien:
- Ein Client fordert eine Ressource an, aber auf der Server-Seite tritt ein unerwarteter Fehler auf. Der Server antwortet mit einem
500 Internal Server Error-Statuscode und protokolliert den Fehler zur Untersuchung. - Ein Client versucht, auf einen Service zuzugreifen, der vorübergehend wegen Wartung nicht verfügbar ist. Der Server antwortet mit einem
503 Service Unavailable-Statuscode und kann einenRetry-After-Header hinzufügen, um anzugeben, wann der Service voraussichtlich wieder verfügbar ist. - Ein Client fordert eine Ressource an, die erfordert, dass der Server mit einem Upstream-Server kommuniziert. Wenn der Upstream-Server zu lange für eine Antwort braucht, sendet der Server einen
504 Gateway Timeout-Statuscode an den Client.
Für weitere Informationen zu HTTP-Statuscodes können Sie auf folgende Ressourcen zurückgreifen:
Umgang mit HTTP-Antworten in der Webentwicklung
Bei der Entwicklung von Webanwendungen müssen Sie HTTP-Antworten sowohl auf der Client- als auch auf der Server-Seite richtig handhaben. Dies trägt zu einer guten Benutzererfahrung bei und hilft beim Debugging und bei der Wartung der Anwendung.
Client-Seite
Auf der Client-Seite, zum Beispiel in einem Webbrowser oder einer mobilen App, müssen Sie:
Statuscodes prüfen: Nach dem Senden einer HTTP-Anfrage sollte der Client den HTTP-Statuscode der Antwort prüfen, um festzustellen, ob die Anfrage funktioniert hat oder nicht. Zum Beispiel:
Statuscode Bedeutung 200 OK Erfolg 404 Angeforderte Ressource nicht gefunden Antwortdaten verarbeiten: Basierend auf dem Statuscode und dem
Content-Type-Header-Feld muss der Client den Antwort-Body auf die richtige Weise verarbeiten. Zum Beispiel:Content-Type Aktion HTML Browser wird es darstellen JSON In ein Objekt zur weiteren Verwendung parsen Weiterleitungen und Fehler behandeln: Wenn der Statuscode eine Weiterleitung bedeutet (3xx-Codes), sollte der Client der neuen URL im
Location-Header folgen. Bei Client-Fehlern (4xx) und Server-Fehlern (5xx) sollte der Client dem Benutzer Fehlermeldungen anzeigen und möglicherweise die Anfrage wiederholen oder den Benutzer auffordern, etwas zu tun.
Beispiel für die Behandlung einer HTTP-Antwortnachricht in JavaScript mit der Fetch API:
fetch('https://api.example.com/data')
.then(response => {
if (!response.ok) {
throw new Error(`HTTP-Fehler! Status: ${response.status}`);
}
return response.json();
})
.then(data => {
console.log(data);
// Daten verarbeiten
})
.catch(error => {
console.error('Fehler:', error);
// Fehler behandeln
});
Server-Seite
Auf der Server-Seite müssen Sie:
Die richtigen Statuscodes und Header setzen: Beim Senden einer Antwort sollte der Webserver den richtigen HTTP-Statuscode setzen, um das Ergebnis der Verarbeitung der Anfrage anzuzeigen. Er sollte auch Antwort-Header-Felder wie
Content-Typeeinschließen, um dem Client zu helfen, die Antwort richtig zu verstehen.Klare Fehlermeldungen bereitstellen: Bei Client- und Server-Fehlerantworten sollte der Server eine klare und kurze Fehlermeldung im Antwort-Body einschließen. Dies hilft Entwicklern zu verstehen, was schiefgelaufen ist und wie es behoben werden kann.
Gute Fehlerbehandlung und Protokollierung implementieren: Auf dem Server ist es wichtig, Fehler gut zu erfassen und zubehandeln. Das bedeutet, Fehler zur späteren Analyse und zum Debugging zu protokollieren und keine sensiblen Daten in Fehlermeldungen offenzulegen, die an den Client gesendet werden.
Beispiel für das Senden einer HTTP-Antwort in Node.js mit Express:
app.get('/data', (req, res) => {
try {
const data = getDataFromDatabase();
res.status(200).json(data);
} catch (error) {
console.error('Fehler:', error);
res.status(500).json({ error: 'Interner Server-Fehler' });
}
});
