HTTP

Klippstein IT Service

Aus 4webmaster.de

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Mit dem HTTP Hypertext Transfer Protocol lässt sich eine beliebige Datei von einem entfernten Computer auf den eigenen übertragen. HTTP ist ein Netzwerkprotokoll auf der obersten Ebene des TCP/IP-Referenzmodell, der Anwendungsschicht. Es ist das wichtigste Protokoll für die Kommunikation zwischen Webserver und Browser.

Beispiel

Die Webseite http://example.net/infotext.html soll übertragen werden. Dazu bekommt der Computer mit dem Hostnamen example.net eine HTTP-Anfrage, die Ressource /infotext.html zurückzusenden.

HTTP-Anfrage:

GET /infotext.html HTTP/1.1
Host: example.net

Bei der Anfrage können auch zusätzliche Informationen wie Angaben über den Browser, gewünschte Sprache etc. übertragen werden, siehe HTTP-Header. Die Anfrage wird via TCP Transmission Control Protocol versendet. Im Rahmen der TCP-Kommunikation wird eine IP-Adresse und eine Portnummer verwendet, aber das passiert alles auf den unteren Schichten des TCP/IP-Referenzmodells.

Der Webserver auf example.net empfängt die Anfrage und sendet die gewünschte Resource zurück:

HTTP-Antwort:

HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html; charset=utf-8
Content-Language: de 

(Inhalt von infotext.html) 

Die Antwort besteht aus dem HTTP-Header und den eigentlichen Daten. Wenn die Information aus irgendeinem Grund nicht gesendet werden kann, sendet der Server eine Fehlermeldung zurück. Weiter unten finden Sie ausführlichere Beispiele.

Zustandslosigkeit

HTTP ist ein zustandsloses Protokoll. Das bedeutet, dass alle Anfragen ohne Bezug zu früheren Anfragen behandelt werden. Der Server „vergisst“ sozusagen, dass er mit einem bestimmten Client jemals kommuniziert hat, zumindest richtet er sein Kommunikationsverhalten nicht danach aus. Das kann sehr hinderlich sein, z.B. wenn ein User einen Login-Status behalten soll oder einen Warenkorb füllt. Es gibt verschiedene Möglichkeiten, die Zustandslosigkeit zu überwinden, z.B. mit Cookies. Siehe Artikel Session.

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. So wird die Ladezeit für die gesamte Seite signifikant verkürzt. Zusätzlich können bei HTTP/1.1 abgebrochene Übertragungen fortgesetzt werden.

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. Damit ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein traceroute auf Anwendungsebene.

Normalerweise kann die Information, die über HTTP übertragen wird, auf allen Rechnern und Routern, die im Netzwerk durchlaufen werden, gelesen werden. Über HTTPS Hypertext Transfer Protocol Secure kann die Übertragung auch verschlüsselt erfolgen.

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

REST verwendet 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

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

Hier wird der sogenannte „Anfrage-Teil“ der URI (beginnt mit dem Zeichen „?“) zur Übertragung von Daten 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 dann 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.

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 dann 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

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

Hauptartikel: HTTP-Statuscodes

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 trotzdem an. Eine solche Zwischenantwort ist zum Beispiel notwendig, wenn die Bearbeitung der Anfrage sehr lange dauert, 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 Beschreibung des Fehlers als englischsprachigen Klartext. Zum Beispiel ist ein Fehler 404 an folgendem Header zu erkennen:

HTTP/1.1 404 Not Found
...

Siehe auch


Weblinks

  • RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1)




Dieser Artikel basiert auf dem Artikel Hypertext_Transfer_Protocol aus der freien Enzyklopädie Wikipedia. Er steht unter der GNU-Lizenz für freie Dokumentation. In diesem Wiki und / oder der Wikipedia ist eine Liste der Autoren verfügbar.



Diese Seite muss überarbeitet werden