FANDOM


HTTP (Hypertext Transfer Protocol)
Familie: Internetprotokollfamilie
Einsatzgebiet: Datenübertragung,
Hypertext u. a.
Port: 80/TCP

Vorlage:Netzwerk-TCP-IP-Anwendungsprotokoll

Standards:

RFC 1945 (HTTP/1.0, 1996)
RFC 2616 (HTTP/1.1, 1999)

Das Hypertext Transfer Protocol (HTTP, engl. Hypertext-Übertragungsprotokoll) 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.

HTTP gehört der so genannten Anwendungsschicht etablierter Netzwerkmodelle an. Die Anwendungsschicht wird von den Anwendungsprogrammen angesprochen, im Fall des HTTP ist dies meistens ein Webbrowser. Im ISO/OSI-Schichtenmodell entspricht die Anwendungsschicht der Schicht 5–7.

Im Kern ist HTTP ein zustandsloses Protokoll. Das bedeutet auch, dass nach erfolgreicher Datenübertragung die Verbindung zwischen den beiden Kommunikationspartnern nicht aufrechterhalten zu werden braucht. Sollen 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 durch eine Sitzung implementiert werden.

Durch Erweiterung seiner Anfragemethoden, Header-Informationen und Statuscodes ist das HTTP 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 geboren wurde.

Aufbau Bearbeiten

Die Kommunikationseinheiten im HTTP zwischen Client und Server werden als Nachrichten bezeichnet, von denen es zwei unterschiedliche Arten gibt: Die Anfrage (engl. Request) vom Client an den Server und die Antwort (engl. Response) als Reaktion darauf vom Server zum Client. Jede Nachricht besteht dabei aus zwei Teilen, dem Nachrichtenkopf (engl. Message Header, kurz: Header oder auch HTTP-Header genannt) und dem Nachrichtenkörper (engl. Message Body, kurz: Body). Der Nachrichtenkopf enthält dabei wichtige Informationen über den Nachrichtenkörper wie etwa verwendete Kodierungen oder den Inhaltstyp, damit dieser vom Empfänger korrekt interpretiert werden kann. Der Nachrichtenkörper enthält schließlich die Nutzlast.

Funktionsweise Bearbeiten

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

Enthält der Link Zeichen, die in der Anfrage nicht erlaubt sind, werden diese %-kodiert. 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 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, PHP und ASP.NET).

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 (nach ISO 639 und ISO 3166)
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 Bearbeiten

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. Mit Hilfe 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 der Weg zum Webserver verfolgt und überprüft werden kann, ob die Daten korrekt dorthin übertragen werden. Damit ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein traceroute auf Anwendungsebene.

HTTP-Request-Methoden Bearbeiten

  • 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. Heute kaum noch implementiert (vergl. dazu WebDAV), war es in der Anfangszeit des WWW eine tatsächlich genutzte Möglichkeit.
  • DELETE löscht die angegebene Datei auf dem Server. Dies ist heutzutage ebenso wie der PUT-Befehl kaum noch implementiert bzw. in der Standardkonfiguration aktueller Webserver abgeschaltet.
  • 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 Proxyservern implementiert, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen.

RESTful Web Services verwenden die unterschiedlichen Request-Methoden zur Realisierung von Web-Services. Insbesondere werden dafür die HTTP-Request-Methoden GET, POST, PUT und DELETE verwendet.

WebDAV fügt folgende Methoden zu HTTP hinzu: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK

Argumentübertragung Bearbeiten

Häufig will der Nutzer einer Website spezielle Informationen senden. Dazu stellt HTTP prinzipiell zwei Möglichkeiten zur Verfügung:

  1. Übertragung der Daten zusammen mit der Anfrage nach einer Ressource (HTTP-Methode GET). Die Daten befinden sich dabei in der URL und bleiben deshalb bei Speichern oder Weitergabe des Links erhalten.
  2. Übertragung der Daten mit einer speziell dazu vorgesehenen Anfrageart (HTTP-Methode POST). Da sich die Daten nicht in der URL befinden, können per POST auch große Datenmengen, z. B. Bilder, übertragen werden.

Auch hier werden zu übertragende Daten oft %-kodiert.

Hier zwei Beispiele, welche die Übertragung von Argumenten bei den Methoden GET und POST zeigen.

HTTP GET Bearbeiten

Hier wird zur Übertragung von Daten der sogenannte „Anfrage-Teil“ des Uniform Resource Identifiers, der mit dem Zeichen ? beginnt, genutzt.

Oft wird diese Vorgehensweise gewählt, um eine Liste von Parametern zu übertragen, die die Gegenstelle bei der Bearbeitung einer Anfrage berücksichtigen soll. Häufig besteht diese Liste aus mit dem Zeichen & getrennten Wertepaaren, die je aus einem Parameternamen, dem Zeichen = und dem Wert des Parameters bestehen. Seltener wird das Zeichen ; zur Trennung von Einträgen der Liste benutzt.[1]

Ein Beispiel: Auf der Startseite von Wikipedia wird in das Eingabefeld der Suche „Katzen“ eingegeben und auf die Schaltfläche „Artikel“ geklickt. Der Browser sendet folgende oder ähnliche Anfrage an den Server:

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 diese 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.)

HTTP POST Bearbeiten

Im folgenden Beispiel wird wieder der Artikel Katzen angefordert, doch diesmal verwendet der Browser aufgrund eines modifizierten HTML-Codes (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 Bearbeiten

Jede HTTP-Anfrage wird vom Server mit einem HTTP-Statuscode beantwortet. Er gibt zum Beispiel Informationen darüber, ob die Anfrage erfolgreich bearbeitet wurde oder teilt dem Client, also etwa dem Browser, im Fehlerfall mit, wo (z. B. Umleitung) bzw. wie (z. B. mit Authentifizierung) er die gewünschten Informationen (wenn möglich) erhalten kann.

1xx Informationen
Die Bearbeitung der Anfrage dauert trotz der Rückmeldung noch an. Eine solche Zwischenantwort ist manchmal notwendig, da viele Clients nach einer bestimmten Zeitspanne (Timeout) automatisch annehmen, dass ein Fehler bei der Übertragung oder Verarbeitung der Anfrage aufgetreten ist, und mit einer Fehlermeldung abbrechen.
2xx Erfolgreiche Operation

Die Anfrage wurde bearbeitet und die Antwort wird an den Anfragesteller zurückgesendet.

3xx Umleitung
Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich. Dies ist zum Beispiel der Fall, wenn eine Webseite vom Betreiber umgestaltet wurde, sodass sich eine gewünschte Datei nun an einem anderen Platz befindet. Mit der Antwort des Servers erfährt der Client im Location-Header, wo sich die Datei jetzt befindet.
4xx Client-Fehler
Bei der Bearbeitung der Anfrage ist ein Fehler aufgetreten, der im Verantwortungsbereich des Clients liegt. Ein 404 tritt beispielsweise ein, wenn ein Dokument angefragt wurde, das auf dem Server nicht existiert. Ein 403 weist den Client darauf hin, dass es ihm nicht erlaubt ist, das jeweilige Dokument abzurufen. Es kann sich zum Beispiel um ein vertrauliches Dokument handeln.
5xx Server-Fehler
Es ist ein Fehler aufgetreten, dessen Ursache beim Server liegt. Zum Beispiel bedeutet 501, dass der Server nicht über die erforderlichen Funktionen (d. h. zum Beispiel Programme oder andere Dateien) verfügt, um die Anfrage zu bearbeiten.

Zusätzlich zum Statuscode enthält der Header der Server-Antwort eine festgelegte Beschreibung des Fehlers im englischsprachigem Klartext. Zum Beispiel ist ein Fehler 404 an folgendem Header zu erkennen:

HTTP/1.1 404 Not Found
…

HTTP-Authentifizierung Bearbeiten

Stellt der Webserver fest, dass für eine angeforderte Datei Benutzername oder Passwort nötig sind, meldet er das dem Browser mit dem Statuscode 401 Unauthorized und dem Header WWW-Authenticate. Größere Webauftritte verwenden dieses standardisierte Verfahren jedoch nur selten, da sich die Eingabefelder für Benutzername und Passwort nur mit Javascript in die Webseite einbetten lassen. Dieser Javascript-Anmeldung sollte keine Barriere darstellen, wenn ohne Javascript die gewohnte Passwort-Abfrage des Browsers erscheint. Auf kleinen Homepages ist HTTP-Authentifizierung aber oft zu finden, da viele Webspaceanbieter eine simple Möglichkeit zur Konfiguration bieten.

Es gibt mehrere Möglichkeiten, Benutzer (Clients) zu authentifizieren. Verbreitet sind:

Basic Authentication Bearbeiten

Die Basic Authentication nach RFC 2617 ist die häufigste Art der HTTP-Authentifizierung. Der Webserver fordert mit

WWW-Authenticate: Basic realm="RealmName"
Datei:HTTPBasicAuth.jpg

eine Authentifizierung an, wobei RealmName eine Beschreibung des geschützten Bereiches darstellt. Der Browser sucht daraufhin nach Benutzername/Passwort für diese Datei und fragt gegebenenfalls den Benutzer. Anschließend sendet er die Authentifizierung mit dem Authorization-Header in der Form Benutzername:Passwort Base64-codiert an den Server. Beispiel:

Authorization: Basic d2lraTpwZWRpYQ==

d2lraTpwZWRpYQ== ist die Base64-Codierung von wiki:pedia und steht damit für Benutzername wiki, Passwort pedia. Ein Nachteil dieses Verfahrens ist, dass Benutzername und Passwort nur aus technischen Gründen codiert, jedoch nicht verschlüsselt werden. Bei einer Verschlüsselung mit SSL/TLS bei HTTPS wird bereits vor der Übermittlung des Passwortes eine verschlüsselte Verbindung aufgebaut, so dass auch bei Basic Authentication das Passwort nicht abhörbar ist.

Digest Access Authentication Bearbeiten

Bei der Digest Access Authentication (ebenfalls RFC 2617) sendet der Server zusammen mit dem WWW-Authenticate-Header eine eigens erzeugte zufällige Zeichenfolge. Der Browser berechnet die Prüfsumme (in der Regel MD5) einer Kombination aus Benutzername, Passwort, erhaltener Zeichenfolge, HTTP-Methode und angeforderter URI. Diese sendet er im Authorization-Header zusammen mit dem Benutzername und der zufälligen Zeichenfolge zurück an den Server. Dieser berechnet seinerseits die Prüfsumme und vergleicht. Ein Abhören der Kommunikation nützt dem Angreifer nichts, da sich die Prüfsumme nicht entschlüsseln lässt und für jede Anforderung anders lauten muss. Die restliche Datenübertragung ist jedoch nicht geschützt. Um dies zu erreichen, sollte HTTPS verwendet werden.

NTLM HTTP Authentication Bearbeiten

In Intranets mit Windows-Servern wird häufig das proprietäre NTLM-Authentifizierungsschema angewandt.

Siehe auch Bearbeiten

Verweise Bearbeiten

  1. Ampersands in URI attribute values in der W3C-HTML 4.01 Specification, Appendix B: Performance, Implementation, and Design Notes

Weblinks Bearbeiten

az:HTTP bg:HTTP bn:হাইপার টেক্সট ট্রান্সফার প্রোটোকল bs:Hypertext Transfer Protocol ca:Protocol de transferència d'hipertext cs:Hypertext Transfer Protocol cy:HTTP da:HTTP el:Πρωτόκολλο Μεταφοράς Υπερκειμένου en:Hypertext Transfer Protocol eo:Hiperteksto-Transiga Protokolo es:Hypertext Transfer Protocol et:Hypertext Transfer Protocol eu:HTTP fa:پروتکل انتقال ابرمتن fi:HTTP fr:Hypertext Transfer Protocol ga:Prótacal Aistrithe Hipirtéacs gl:HTTP he:Hypertext Transfer Protocol hr:HTTP hu:HTTP id:HTTP is:HTTP it:HTTP ja:Hypertext Transfer Protocol ko:HTTP lb:Hypertext Transfer Protocol lt:HTTP lv:HTTP ml:എച്ച്‌.ടി.ടി.പി. ms:HTTP nl:Hypertext Transfer Protocol nn:Hypertext Transfer Protocol no:HTTP pl:Hypertext Transfer Protocol pt:HTTP ro:HTTP ru:HTTP sh:HTTP simple:Hypertext Transfer Protocol sk:Hypertext Transfer Protocol sl:HTTP sq:HTTP sr:HTTP sv:HTTP th:Hypertext Transfer Protocol tl:HTTP tr:HTTP uk:HTTP vi:Hypertext Transfer Protocol zh:超文本传输协议