HTTP: Das Hypertext Transfer Protocol (einfach erklärt)

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.

Weiterführende Links

  1. YouTube • OSI-Referenzmodell - Schicht 5 (HTTP)
  2. RFC 1945 • HTTP-Spezifikation Version 1.0
  3. RFC 2616 • HTTP-Spezifikation Version 1.1

Hinweis:
Dies ist ein älterer Artikel von meinem alten Blog. Die Kommentare zu diesem Artikel werden (falls vorhanden) später noch hinzugefügt.

Der Autor

Unter dem Namen »TheBlackPhantom« alias »BlackY« veröffentlichte ich auf meinem alten Blog, BlackPhantom.DE, in der Zeit von 2011 bis 2015 leidenschaftlich Beiträge über Computer, Internet, Sicherheit und Malware. Während der BlackPhantom-Zeit war ich noch grün hinter den Ohren und lernte viel dazu. Mehr Infos vielleicht in Zukunft...