Hypertext Transfer Protocol
| HTTP (Hypertext Transfer Protocol) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Familie: | Internetprotokollfamilie | ||||||||||||||||||||||||
| Einsatzgebiet: | Datenübertragung, Hypertext u. a. | ||||||||||||||||||||||||
| Port: | (meist) 80/TCP | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
| Standards: | |||||||||||||||||||||||||
Das Hypertext Transfer Protocol (HTTP) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten und andere Daten aus dem World Wide Web (WWW) in einen Webbrowser zu laden.
Datenübertragung in Netzwerken ist ein komplexes Problem: Sollen die Daten zentral gesteuert oder dezentral übertragen werden, wie sollen die reine Information und die Daten zur ihrer Weitervermittlung getrennt sein usw. Um dieses zu lösen, unterteilt man es in mehrere triviale Probleme und bildet diese in Schichtenmodellen ab. Jede Schicht ist für die Lösung eines solchen trivialen Problems verantwortlich und bietet diese der darüberliegenden Schicht als Dienstleistung an. Das HTTP bildet die so genannte Anwendungsschicht, über der die Modelle keine weiteren Schichten vorsehen. Die Anwendungsschicht wird von den Anwendungsprogrammen angesprochen, im Fall des HTTP ist dies meistens der Webbrowser, diese Schicht hat der normale Nutzer somit vor sich, wenn er eine Webadresse eingibt. Im ISO/OSI-Schichtenmodell entspricht die Anwendungsschicht der Schicht 7. Das im Internet angewendete TCP/IP-Referenzmodell sieht die Anwendungsschicht in Schicht 4.
Im Kern ist HTTP ein zustandsloses Protokoll. Das bedeutet auch, dass nach erfolgreicher Datenübertragung die Verbindung zwischen den beiden Kommunikationspartnern nicht aufrecht erhalten werden muss. Sollen dann weitere Daten übertragen werden, muss zunächst eine weitere Verbindung aufgebaut werden. Auch ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht, zum Beispiel durch Cookies, implementiert werden.
Durch Erweiterung seiner Anfragemethoden, Header-Informationen und Statuscodes ist das HTTP allerdings nicht auf Hypertext beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet. Zur Kommunikation ist HTTP auf ein zuverlässiges Transportprotokoll angewiesen. In nahezu allen Fällen wird hierfür TCP verwendet.
Das Protokoll wurde 1989 von Tim Berners-Lee am CERN zusammen mit dem URL und der HTML entwickelt, wodurch praktisch das World Wide Web (WWW) geboren wurde.
Funktionsweise
HTTP ist ein Kommunikationsschema, um Webseiten (oder Bilder oder prinzipiell jede andere beliebige Datei) von einem entfernten Computer auf den eigenen zu übertragen. Wenn auf einer Webseite der Link zum URL http://www.example.net/infotext.html aktiviert wird, so wird an den Computer mit dem Hostnamen www.example.net die Anfrage gerichtet, die Ressource /infotext.html zurückzusenden.
Der Name www.example.net wird dabei zuerst über das DNS-Protokoll in eine IP-Adresse umgesetzt. Zur Übertragung wird über das TCP-Protokoll auf den Standard-Port 80 des HTTP-Servers eine HTTP-GET-Anforderung gesendet.
Anfrage:
GET /infotext.html HTTP/1.1 Host: www.example.net
Zusätzliche Informationen wie Angaben über den Browser, zur gewünschten Sprache etc. können über den Header (Kopfzeilen) in jeder HTTP-Kommunikation übertragen werden. Sobald der Header mit einer Leerzeile abgeschlossen wird, sendet dann der Computer, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück. Diese besteht aus den Header-Informationen des Servers, einer Leerzeile und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt der infotext.html-Datei. Übertragen werden normalerweise Dateien in Seitenbeschreibungssprachen wie (X)HTML und alle ihre Ergänzungen, zum Beispiel Bilder, Stylesheets (CSS), Skripte (JavaScript) usw., die meistens von einem Browser in einer lesbaren Darstellung miteinander verbunden werden. Prinzipiell kann jede Datei in jedem beliebigen Format übertragen werden, wobei die „Datei“ auch dynamisch generiert werden kann und nicht auf dem Server als physische Datei vorhanden sein muss (z. B. bei Anwendung von SSI, JSP und PHP).
Antwort:
HTTP/1.1 200 OK Server: Apache/1.3.29 (Unix) PHP/4.3.4 Content-Length: (Größe von infotext.html in Byte) Content-Language: de Content-Type: text/html Connection: close (Inhalt von infotext.html)
Der Server sendet eine Fehlermeldung zurück, wenn die Information aus irgendeinem Grund nicht gesendet werden kann. Der genaue Ablauf dieses Vorgangs (Anfrage und Antwort) ist in der HTTP-Spezifikation festgelegt.
Protokollversionen
Derzeit werden zwei Protokollversionen, HTTP/1.0 und HTTP/1.1 verwendet.
Bei HTTP/1.0 wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort wieder geschlossen. Sind in ein HTML-Dokument beispielsweise zehn Bilder eingebettet, so werden insgesamt elf TCP-Verbindungen benötigt, um die Seite auf einem grafikfähigen Browser aufzubauen.
In der Version 1.1 können mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für das HTML-Dokument mit zehn Bildern wird so nur eine TCP-Verbindung benötigt. Da die Geschwindigkeit von TCP-Verbindungen zu Beginn auf Grund des Slow-Start-Algorithmus recht gering ist, wird so die Ladezeit für die gesamte Seite signifikant verkürzt. Zusätzlich können bei HTTP/1.1 abgebrochene Übertragungen fortgesetzt werden.
Bei HTTP gehen Informationen aus früheren Anforderungen verloren (zustandsloses Protokoll). Über Cookies in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können. Dadurch können Anwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich.
Normalerweise kann die Information, die über HTTP übertragen wird, auf allen Rechnern und Routern, die im Netzwerk durchlaufen werden, gelesen werden. Über HTTPS kann die Übertragung verschlüsselt erfolgen.
Eine Möglichkeit zum Einsatz von HTTP/1.1 in Chats ist die Verwendung des MIME-Typs multipart/replace, bei dem der Browser nach Sendung eines Boundary-Codes und einem neuerlichen Content-Length-Headerfeld sowie eines neuen Content-Type-Headerfeldes den Inhalt des Browserfensters komplett erneuert.
Mit HTTP/1.1 ist es neben dem Abholen von Daten auch möglich, Daten zum Server zu übertragen. Mithilfe der PUT-Methode können so Webdesigner ihre Seiten direkt über den Webserver per WebDAV publizieren, und mit der DELETE-Methode ist es ihnen möglich, Daten vom Server zu löschen.
Außerdem bietet HTTP/1.1 eine TRACE-Methode, mit der man den Weg zum Webserver verfolgen kann und überprüfen kann, ob die Daten korrekt dorthin übertragen werden. Mithilfe dieser Methode ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein traceroute auf Anwendungsebene.
HTTP-Request-Methoden
- GET ist die gebräuchlichste Methode. Mit ihr werden Inhalte vom Server angefordert.
- POST ähnelt der GET-Methode, nur dass ein zusätzlicher Datenblock übermittelt wird. Dieser besteht üblicherweise aus Name/Wert-Paaren, die aus einem HTML-Formular stammen. Grundsätzlich können Daten auch mittels GET übertragen werden (als Argumente im URI), aber die Übertragung der Argumente erfolgt bei POST diskret (wichtig bei sensiblen Daten) und die zulässige Datenmenge ist deutlich größer.
- HEAD weist den Server an, die gleichen HTTP-Header wie ein GET oder POST, nicht jedoch den eigentlichen Dokumentinhalt selbst zu senden. So kann zum Beispiel schnell die Gültigkeit einer Datei im Browsercache geprüft werden.
- PUT dient dazu, Dateien unter Angabe des Ziel-URIs auf einen Webserver hochzuladen. Dies ist jedoch kaum implementiert.
- DELETE löscht die angegebene Datei auf dem Server. Dies ist jedoch kaum implementiert.
- TRACE liefert die Anfrage so zurück, wie der Server sie empfangen hat. So kann überprüft werden, ob und wie die Anfrage auf dem Weg zum Server verändert worden ist – sinnvoll für das Debugging von Verbindungen.
- OPTIONS liefert eine Liste der vom Server unterstützen Methoden und Features.
- CONNECT wird von Proxy-Servern implementiert, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen.
Argumentübertragung
Häufig will der Nutzer einer Website spezielle Informationen senden. Dies erfolgt in Form von URL-Argumenten. Hier zwei Beispiele, welche die Übertragung von Argumenten bei den Methoden GET und POST zeigen. Zum Verständnis sind Kenntnisse über die HTTP-Header sinnvoll. Beschreibung der HTTP-Header
Auf der Startseite von Wikipedia wird Katzen eingegeben und auf Artikel geklickt. Der Browser sendet dann folgende oder ähnliche Anfrage:
GET /wiki/Spezial:Search?search=Katzen&go=Artikel HTTP/1.1 Host: de.wikipedia.org ...
Dem Wikipedia-Server werden zwei Wertepaare übergeben:
| Argument | Wert |
|---|---|
| search | Katzen |
| go | Artikel |
Diese Wertepaare werden in der Form
Argument1=Wert1&Argument2=Wert2
mit ? an die geforderte Seite angehängt.
Dadurch „weiß“ der Server, dass der Nutzer den Artikel Katzen betrachten will. Der Server verarbeitet die Anfrage, sendet aber keine Datei, sondern leitet den Browser mit einem Location-Header zur richtigen Seite weiter, etwa mit:
HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2006 15:12:44 GMT Location: http://de.wikipedia.org/wiki/Katzen ...
Der Browser befolgt dieser Anweisung und sendet aufgrund der neuen Informationen eine neue Anfrage, etwa:
GET /wiki/Katzen HTTP/1.1 Host: de.wikipedia.org ...
Und der Server antwortet und gibt den Artikel Katzen aus, etwa:
HTTP/1.0 200 OK Date: Fri, 13 Jan 2006 15:12:48 GMT Last-Modified: Tue, 10 Jan 2006 11:18:20 GMT Content-Language: de Content-Encoding: gzip Content-Type: text/html; charset=utf-8 .‹........´ZKs.¹.>Û¿.ž-[¶KÃ!õ²ÌÇlô²¬ìuVò*ÉÖ– 3.r`Î+.F”xÊ!ÿ ×.ý.ö´7ý“ü’t.ó"9ÔʛĮ.A.ÐÝ
Der Datenteil ist natürlich viel länger, wird hier jedoch ausgelassen, da nur das Protokoll betrachtet wird. (Er ist hier aufgrund der im Beispiel genutzten gzip-Komprimierung ohnehin unlesbar.)
Im folgenden Beispiel wird wieder der Artikel Katzen angefordert, doch diesmal verwendet der Browser aufgrund der HTML-Angabe method="POST" eine POST-Anfrage. Die Variablen stehen dabei nicht in der URI sondern gesondert im Body-Teil, etwa:
POST /wiki/Spezial:Search HTTP/1.1 Host: de.wikipedia.org Content-Type: application/x-www-form-urlencoded Content-Length: 24 search=Katzen&go=Artikel
Auch das versteht der Server und antwortet wieder mit beispielsweise Folgendem:
HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2006 15:32:43 GMT Location: http://de.wikipedia.org/wiki/Katzen ...
HTTP-Statuscodes
| 1XX | Informationen | Die Bearbeitung der Anfrage dauert trotzdem an. |
| 2XX | Erfolgreiche Operation | Die Bearbeitung der Anfrage kann durchgeführt werden. |
| 3XX | Umleitung | Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich. |
| 4XX | Client-Fehler | Nicht klar von den so genannten Server-Fehlern abzugrenzen. Die Ursache des Scheiterns der Anfrage liegt jedoch eher im Verantwortungsbereich des Clients. |
| 5XX | Server-Fehler | Nicht klar von den so genannten Client-Fehlern abzugrenzen. Die Ursache des Scheiterns der Anfrage liegt jedoch eher im Verantwortungsbereich des Servers. |
Vollständige Liste: HTTP-Statuscodes
HTTP-Authentifizierung
Es gibt mehrere Möglichkeiten, Benutzer (Clients) zu authentifizieren. Verbreitet sind:
- Basic Authentication (RFC 2617)
- Digest Access Authentication (ebenfalls RFC 2617)
- NTLM HTTP Authentication (in Intranets mit Windows-Servern)
Siehe auch
Weblinks
- RFC 1945 (Hypertext Transfer Protocol – HTTP/1.0)
- RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1)
- HyperText Transfer Protocol 1.1, Uni-Frankfurt
- HTTP Anfrage- und Antwort-Header ansehen
- Beschreibung der HTTP-Header
- Beschreibung der HTTP Status-Codes
- Ein (Freeware) HTTP Protokoll Analysator
- Linkkatalog zum Thema HTTP bei curlie.org (ehemals DMOZ)