Das Hypertext Transfer Protocol, kurz HTTP, ist ein zustandsloses Protokoll, das hauptsächlich für die Übertragung von Inhalten aus dem Internet zuständig ist. So werden Webseiten und all die dazugehörigen Elemente über das Hypertext Transfer Protocol übertragen, welches eine TCP/IP-Verbindung zum Transport benutzt.
Da das Protokoll an sich zustandslos ist, ist ein Mitführen von Sitzungsinformationen nicht möglich. Genauer gesagt vergisst das Hypertext Transfer Protocol alle Informationen aus einer Anfrage wieder, sobald sie bearbeitet wurde. Es besteht also kein Zusammenhang zwischen der einen Anfrage und der nächsten, so wie z.B. bei einer TCP-Verbindung. Die Kommunikation erfolgt standardmäßig auf Port 80/TCP (unverschlüsselt) und auf Port 443/TCP (verschlüsselt).
Aufbau eines HTTP-Requests
Wenn ein Client eine Anfrage an den HTTP-Server (Webserver) einer Internetseite schickt, dann nennt man das "Request". Da es auf einen Request in der Regel auch immer eine Antwort gibt, nennt man dies "Response". Der Client schickt einen Request an den Webserver und bekommt als Antwort darauf also einen Response zurück.
Jeder Request und jeder Response enthält zwei Fragmente:
Das sind einmal der Nachrichtenkopf ("Header") und der Nachrichtenkörper ("Body"). Im Header des HTTP-Requests befinden sich immer wichtige Informationen, wie zum Beispiel die angeforderte Ressource (URL) auf dem Webserver oder Cookie-Informationen, die vom Client zum Webserver (oder umgekehrt) geschickt werden.
Im Body, dem Nachrichtenkörper einer HTTP-Antwort, befindet sich dann der eigentliche Inhalt. Dies ist dann in der Regel die HTML-Seite, die dann vom Webbrowser interpretiert und dargestellt wird. Auch Grafiken und andere Elemente einer Webseite befinden sich im Body einer HTTP-Antwort.
Kommunikation zwischen Server und Client
Wenn ein Webbrowser beispielsweise die Webseite http://example.com/home.php
aufrufen möchte, dann wird der folgende HTTP-Request zum Server geschickt und der Server wird daraufhin mit einem Response antworten. Genauer gesagt wird hier ein GET
-Request abgeschickt. Die Erklärung der verschiedenen Request-Methoden und was die Unterschiede sind erfolgt im weiteren Verlauf dieses Artikels.
Die HTTP-Anfrage ("Request")
In der ersten Zeile wird zuerst die Request-Methode festgelegt. Dann folgt der Pfad zur gewünschten Ressource und die zu verwendende HTTP-Protokollversion. In der zweiten Zeile wird der Hostname der Webseite angegeben. Dieser sollte immer im HTTP-Header drin stehen, denn sonst kann der Webserver die Anfrage unter Umständen nicht beantworten und meldet im Response den HTTP-Statuscode 400 Bad Request
zurück. Die Request-Methode, der Pfad zur Ressource und die Protokollversion müssen zwingend angegeben werden.
GET /home.php HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0
Referer: http://www.google.com/?q=blackphantom
Die zwei letzten Zeilen sind optionale Parameter, die vom Webbrowser automatisch gesetzt werden. Dabei handelt es sich einmal um den Useragent und einmal um den Referrer. Der Useragent enthält Informationen über das Betriebssystem und welcher Browser verwendet wird. Der Referer enthält den Link zur Seite, von wo der Benutzer gekommen ist.
Die HTTP-Antwort ("Response")
Kommen wir nun zum Response der oben gezeigten GET
-Anfrage.
Es wurde eine GET
-Anfrage geschickt, mit der Bitte, die Ressource /home.php
zurückzuliefern. Wenn diese Datei auf dem Server existiert, dann werden wir diese natürlich auch bekommen. Andernfalls, zum Beispiel wenn die Datei nicht existiert, bekommen wir die entsprechende Fehlerseite zurückgeliefert. Wenn wir uns jetzt den HTTP-Response anschauen, dann fällt auf, dass das Ganze nun etwas größer ist – natürlich, es wurde ja auch eine HTML-Seite angefordert.
HTTP/1.1 200 OK
Date: Tue, 18 Dec 2012 01:12:29 GMT
Server: Apache
Connection: close
Content-Type: text/html
<html>
[.....]
</html>
In der ersten Zeile des Response steht die verwendete HTTP-Protokollversion und darauf folgt noch ein HTTP-Statuscode, der dem Browser mitteilt, ob die Anfrage erfolgreich war oder ob Fehler aufgetreten sind. In diesem Fall war die Anfrage in Ordnung und es wird der HTTP-Statuscode 200 OK
ausgegeben. Der bekannteste Statuscode ist wohl 404 Not Found
. Dieser würde zurückgesendet werden, falls die Ressource home.php
auf dem Server nicht existieren würde.
In der zweiten Zeile befindet sich das Headerfeld Date
, in dem der aktuelle Zeitpunkt der Anfrage drin steht. In der dritten Zeile enthält das Headerfeld Server
den Namen der eingesetzten Serversoftware und -Version.
Dann sind da noch Connection
und Content-Type
. Hinter Connection
steht close
. Das bedeutet, dass der Server die darunterliegende TCP-Verbindung abgebaut hat. Neben close
gäbe es noch keep-alive
, mit dem man eine TCP-Verbindung (über die die HTTP-Requests transportiert werden) am Leben erhalten kann. Die Verbindung zum Server würde dann also nicht abgebaut werden, sondern für weitere HTTP-Anfragen offen bleiben.
Im Content-Type
ist angegeben, ob der Nachrichtenteil im Body eine HTML-Seite, ein Bild oder zum Beispiel eine Audiodatei ist. Der Webbrowser empfängt diese Nachricht natürlich und kann dann entsprechend handeln, indem er entweder ein Bild anzeigt oder eine HTML-Seite darstellt. Falls der Webbrowser einen Content-Type mal nicht unterstützt, dann wird die Datei (also der Inhalt des Bodys) standardmäßig als Download angeboten.
Jetzt ist da noch der Body des HTTP-Response, der den eigentlichen Inhalt enthält.
Im Beispiel enthält der Body eine normale HTML-Seite (die vorher auf dem Server über PHP dynamisch generiert wurde). Der Nachrichtenkörper, also der HTTP-Body, beginnt einen Absatz unterhalb des Headers. Alles was davor steht gehört noch zum Header des Response. Der Body kann außer einer HTML-Seite aber auch ein Bild oder eine andere Datei enthalten. Bei einem Bild stehen im Body dann unleserliche Zeichen (binärcodiert), aber der Webbrowser erkennt am Content-Type
und der Eigenschaft image/jpg
, dass es eine Grafik ist und stellt sie dann entsprechend dar. Ohne den Content-Type wüsste der Webbrowser nicht, was er mit dem Body anfangen soll.
Welche HTTP-Request-Methoden gibt es?
Im vorherigen Abschnitt wurde erläutert, wie die Kommunikation zwischen Server und Client abläuft. Dabei wurde ein GET
-Request abgeschickt. Der GET
-Request ist die Standard-Request-Methode, bei der eine Ressource vom Webserver angefordert wird. Natürlich gibt es auch noch weitere Request-Methoden, wie zum Beispiel den POST
-Request. Der POST
-Request ist nach dem GET
-Request der Zweithäufigste. Im Folgenden eine kleine Auflistung der HTTP-Request-Methoden und wie deren HTTP-Header aussehen.
Es gibt natürlich noch weitere Request-Methoden. Da die nachfolgenden drei aber die Wichtigsten sind, lasse ich die anderen Methoden wie PUT
, DELETE
, TRACE
oder OPTIONS
jetzt einfach mal weg. Warum, das erfahrt ihr im Abschnitt "Welche HTTP-Protokollversionen gibt es".
Der GET
-Request
Der GET-Request ist die standardmäßig verwendete Request-Methode, wenn man eine Verbindung zur einer Webseite aufbaut. Über GET
können allerdings auch Daten verschickt werden. Allerdings ist man wegen der maximal erlaubten URL-Länge von 255 Zeichen sehr eingeschränkt, was das Versenden von größeren Datenmengen angeht. Über GET
sollte man deshalb nur wichtige Parameter für die Webseite übergeben, wie zum Beispiel home.php?id=2
.
GET /home.php HTTP/1.1
Host: example.com
Der POST
-Request
Wenn man eine größere Datenmenge, wie zum Beispiel Dateien oder Texte aus einem HTML-Formular, an den Webserver senden will, dann verwendet man dazu den POST
-Request. Im Gegensatz zu GET
kann man bei POST
je nach Konfiguration des Webservers deutlich mehr Daten schicken. Die Daten werden dabei nicht wie bei GET
an die URL angehängt, sondern befinden sich im HTTP-Body des Requests. Die gesendeten Daten kann man dann mit einer serverseitigen Skriptsprache wie PHP auslesen und weiterverarbeiten.
POST /home.php HTTP/1.1
Host: example.com
field1=value&field2=value&field3=value
Der HEAD
-Request
Dann gibt es da noch die HEAD
-Methode. Diese unterscheidet sich nicht viel von der GET
-Methode. Der einzige Unterschied besteht darin, dass bei einem HEAD
-Response nur der HTTP-Header ohne den HTTP-Body gesendet wird. Wenn man sich aus irgendwelchen Gründen mal nur den HTTP-Response-Header anzeigen lassen will, dann kann man diese Request-Methode verwenden.
HEAD /home.php HTTP/1.1
Host: example.com
Die HTTP-Response-Header
In diesem Abschnitt werden einige Beispiel-Response-Header aufgelistet.
Standard-Response
Hier seht ihr die vollständige Antwort eines Apache-Webservers auf einen normalen GET
- oder POST
-Request.
HTTP/1.1 200 OK
Date: Tue, 01 Jan 2013 22:00:13 GMT
Server: Apache/2.2.21 (Win32) [.....]
X-Powered-By: PHP/5.3.8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
Standard-Response mit Set-Cookie
-Headerfeld
Ebenfalls eine vollständige Antwort auf einen Request, nur dieses mal werden Cookies mitgeschickt, die dann vom Webbrowser gespeichert und bei der nächsten Anfrage an die Webseite wieder mitgeschickt werden.
HTTP/1.1 200 OK
Date: Tue, 01 Jan 2013 22:00:13 GMT
Server: Apache/2.2.21 (Win32) [.....]
X-Powered-By: PHP/5.3.8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: hits=36548; expires=Tue, 01-Jan-2030 00:00:00 GMT; path=/; httponly
Content-Type: text/html
Welche HTTP-Protokollversionen gibt es?
Vom Hypertext Transfer Protocol gibt es zwei Versionen. Das sind einmal das alte HTTP/1.0 und das etwas neuere HTTP/1.1. Für HTTP/2.0 stehen zwar schon die ersten Entwürfe bereit, aber HTTP/1.1 ist immer noch die aktuelle Version.
Die erste Version HTTP/1.0 erschien im Jahr 1996. Bereits drei Jahre später kam dann schon die neuere Version HTTP/1.1, die auch heute noch verwendet wird. Die Unterschiede zwischen den beiden Versionen liegen darin, dass bei HTTP/1.0 für jedes Element einer Webseite eine eigene TCP-Verbindung benötigt wird. Da aber die Ladezeit der Webseite leidet, wenn für jedes Element eine neue TCP-Verbindung auf- und abgebaut wird, wurde das mit HTTP/1.1 behoben und alle Elemente einer Webseite können somit über eine einzige TCP-Verbindung übertragen werden.
Des Weiteren kamen ein paar neue HTTP-Request-Methoden wie PUT
, DELETE
und TRACE
hinzu, mit denen man Dateien zum Server übertragen und auch wieder löschen kann. In der Regel sind diese Funktionen aber aus Sicherheitsgründen in der Apache-Konfiguration standardmäßig deaktiviert. Ansonsten könnten auch unautorisierte Personen Dateien zum Webserver übertragen, löschen und gegebenenfalls Schadcode ausführen.
Außerdem kamen die beiden Request-Methoden OPTIONS
und CONNECT
hinzu. OPTIONS
liefert einem die vom Webserver unterstützten Request-Methoden zurück, während CONNECT
nur für Proxy-Server wirklich relevant ist.