HTTP
HTTP-Antworten

Parameter

Grundlegendes Antwortformat

Wenn ein HTTP-Server eine wohlgeformte HTTP-Anforderung erhält, muss er die in der Anforderung enthaltenen Informationen verarbeiten und eine Antwort an den Client zurückgeben. Eine einfache HTTP 1.1-Antwort kann wie eine der folgenden aussehen, normalerweise gefolgt von einer Reihe von Headerfeldern und möglicherweise einem Antworttext:

HTTP/1.1 200 OK \r\n

HTTP/1.1 404 Not Found \r\n

HTTP/1.1 503 Service Unavailable \r\n

Eine einfache HTTP 1.1-Antwort hat folgendes Format:

HTTP-Version Status-Code Reason-Phrase CRLF

Wie in einer Anfrage gibt die HTTP-Version die Version des verwendeten HTTP-Protokolls an. Für HTTP 1.1 muss dies immer die Zeichenfolge HTTP/1.1 .

Status-Code ist ein dreistelliger Code, der den Status der Anfrage des Kunden angibt. Die erste Ziffer dieses Codes ist die Statusklasse , die den Statuscode in eine von fünf Antwortkategorien ^{[1] einordnet} :

• 1xx Informational - Der Server hat die Anfrage erhalten und die Verarbeitung wird fortgesetzt
• 2xx Erfolg - Der Server hat die Anfrage akzeptiert und verarbeitet
• 3xx Umleitung - Der Client muss weitere Schritte 3xx , um die Anforderung abzuschließen
• 4xx Client-Fehler - Der Client hat eine Anfrage gesendet, die fehlerhaft war oder nicht erfüllt werden konnte
• 5xx Server-Fehler - Die Anforderung war gültig, kann jedoch derzeit vom Server nicht erfüllt werden

Reason-Phrase ist eine kurze Beschreibung des Statuscodes. Beispielsweise hat der Code 200 eine Grundphrase von OK ; Code 404 hat eine Phrase von Not Found . Eine vollständige Liste der Begründungsausdrücke finden Sie in den folgenden Parametern oder in der HTTP-Spezifikation .

Die Zeile endet mit einem Wagenrücklauf-Zeilenvorschubpaar, normalerweise dargestellt durch \r\n .

Zusätzliche Header

Wie eine HTTP-Anfrage kann eine HTTP-Antwort zusätzliche Header enthalten, um die von ihr bereitgestellte Antwort zu ändern oder zu erweitern.

Eine vollständige Liste der verfügbaren Header ist in §6.2 der Spezifikation definiert . Die am häufigsten verwendeten Header sind:

• Server , der wie ein User-Agent Anforderungsheader für den Server fungiert;
• Location , der in den Statusantworten 201 und 3xx verwendet wird, um einen URI anzugeben, an den weitergeleitet werden soll; und
• ETag , eine eindeutige Kennung für diese Version der zurückgegebenen Ressource, damit Clients die Antwort im Cache speichern können.

Antwortheader stehen hinter der Statuszeile und werden wie bei Anforderungsheatern als solche gebildet:

Name: Value CRLF

Name gibt den Headernamen an, z. B. ETag oder Location , und Value gibt den Wert an, den der Server für diesen Header festlegt. Die Zeile endet mit einer CRLF.

Eine Antwort mit Kopfzeilen könnte folgendermaßen aussehen:

HTTP/1.1 201 Created \r\n
Server: WEBrick/1.3.1 \r\n
Location: http://example.com/files/129742 \r\n

Nachrichtenkörper

Wie bei Anforderungskörpern können HTTP-Antworten einen Nachrichtentext enthalten. Dadurch werden zusätzliche Daten bereitgestellt, die der Client verarbeitet. 200 OK-Antworten auf eine wohlgeformte GET-Anforderung sollten immer einen Nachrichtentext enthalten, der die angeforderten Daten enthält. (Wenn dies nicht der Fall ist, ist 204 No Content eine angemessenere Antwort).

Ein Nachrichtentext ist nach allen Kopfzeilen und einer doppelten CRLF enthalten. Bei Anfragen sollte die Länge in Byte mit dem Content-Length Header angegeben werden. Eine erfolgreiche Antwort auf eine GET-Anfrage könnte daher wie folgt aussehen:

HTTP/1.1 200 OK\r\n
Server: WEBrick/1.3.1\r\n
Content-Length: 39\r\n
ETag: 4f7e2ed02b836f60716a7a3227e2b5bda7ee12c53be282a5459d7851c2b4fdfd\r\n
\r\n
Nobody expects the Spanish Inquisition.