HTTP-Protokoll: HTTP-Tutorial Teil-2
HTTP-Protokoll
Im ersten Teil dieses kleinen HTTP-Tutorials drehte sich alles um die HTTP-Statuscodes. Aber bevor wir diese für unsere eigenen Zwecke verwenden oder auswerten können müssen wir uns noch mit dem HTTP-Protokoll auseinander setzen. Das Wissen um die Funktionsweise des HTTP-Protokolls ist Voraussetzung um selbst HTTP-Header samt Statuscode zu erzeugen oder empfangene HTTP-Header richtig auszuwerten. Aus diesem Grund dreht sich im heutigen Artikel alles um das HTTP-Protokoll und wie es funktioniert.
Wer sich jetzt die Frage stellt ob es nicht logischer wäre zuerst das HTTP-Protokoll zu behandeln und erst danach näher auf die Statuscodes einzugehen.. dem kann ich nur sagen… ja, wäre es! Aber da der Auslöser für dieses Tutorial nun mal die HTTP-Statuscodes waren landet das HTTP-Protokoll eben im zweiten Teil. Es steht aber jedem frei erst Teil 2 und dann Teil 1 zu lesen. 
Teil-2: Das HTTP-Protokoll
HTTP-Protokoll… was ist das?
Ich habe es in Teil 1 schon kurz angerissen. Wenn “Geräte” bzw. Programme die auf diesen Geräten laufen über ein Netzwerk (z.B. das Internet) miteinander kommunizieren wollen, dann müssen alle die selbe “Sprache” sprechen. Tun sie dies nicht so versteht keiner den anderen und eine Kommunikation kommt nicht zu Stande. Wenn ich “Geräte” sage dann meine ich im Prinzip alles was einen Netzwerk-Anschluß hat. Das kann zum einen natürlich der klassische PC sein, es könnte sich aber genauso gut um ein Handy, einen Fernseher mit Netzanschluß oder wegen meiner auch einen Kühlschrank handeln, der fehlenden Inhalt automatisch über das Internet bestellt. Will also ein Gerät über das Internet mit anderen Gerätschaften Kontakt aufnehmen so muss es deren Sprache(n) sprechen. Diese Sprachen nennt man auch Protokolle und eins dieser Protokolle ist das HTTP-Protokoll. Im HTTP-Protokoll ist (wie in solchen Protokollen üblich) genau festgelegt wer, was und in welcher Form senden darf und wie und in welcher Form darauf geantwortet werden muss. Auf diese Weise kann jedes Gerät welches die “Sprache” HTTP beherrscht mit jedem anderen Gerät welches auch HTTP spricht kommunizieren. Das berühmteste Beispiel wäre hier sicher der Web-Browser auf einem PC der mit einem Webserver (und umgekehrt) “spricht” bzw. Daten austauscht. Das HTTP-Protokoll ist also in erster Linie, zumindest ursprünglich, darauf ausgelegt Dokumente bzw. Daten anzufordern und auszuliefern.
Und wie genau funktioniert nun das HTTP-Protokoll?
Header und Body
Ganz vereinfacht lässt sich die Kommunikation über HTTP so beschreiben: Zuerst sendet ein Client eine Anfrage in Form eines HTTP-Headers gefolgt von evtl. dazu gehörenden Daten. Der Server bearbeitet die Anfrage und sendet als Antwort wieder einen HTTP-Header gefolgt von evtl. zur Antwort gehörender Daten. Das ist es eigentlich schon. Simpel und einfach. Und es wird noch schöner: Die HTTP-Header werden als ganz normaler Text gesendet. So wie er auch in einer Textdatei stehen könnte: Textzeile+Zeilenvorschub, Textzeile+Zeilenvorschub… Das gibt uns die Möglichkeit die Kommunikation über HTTP problemlos zu beobachten und zu verstehen. Wir brauchen uns nur die jeweiligen Header direkt ansehen. Am Ende wird der Header einer Client-Anfrage oder einer Server-Antwort jeweils durch eine Leerzeile abgeschlossen. Danach folgen evtl. zu übertragene Daten. Nach diesem Prinzip funktioniert die gesamte Kommunikation im Internet die über das HTTP-Protokoll stattfindet. Aber gucken wir uns das lieber anhand eines konkreten Beispiels an…
Beispiel Abfrage einer Webseite:
Für unser erstes Beispiel nehmen wir eine einfache und minimal gehaltene Webseite an, die auf einem Webserver liegt und z.B. so aussieht:
<html>
<head><title>Beispiel-Seite</title></head>
<body>
Eine tolle Webseite !!
</body>
</html>Wenn wir nun mit einem Browser diese Webseite aufrufen so wird dieser in etwa folgende Anfrage an den Webserver senden:
GET /beispielseite.html HTTP/1.1
Host: www.meine-domain.tld
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Connection: close
Was wir hier sehen ist der HTTP-Header der vom Browser an den Webserver gesendet wird und diesem folgendes Mitteilt:
- Zeile 1: Meine Anfrage folgt der Methode “GET” und der HTTP-Version 1.1. Bitte sende mir das Dokument “/beispielseite.html“.
- Zeile 2: Meine Anfrage richtet sich an den Host “www.meine-domain.tld“.
- Zeile 3: Meine Kennung lautet “Mozilla/5.0 (Windows………usw.“
- Zeile 4: Bitte schließe die Verbindung nach dem Senden der Antwort.
Wie man sieht “redet” der Browser mit dem Webserver fast wie mit einem Menschen. Ist das angeforderte Dokument “beispielseite.html” auf dem Server vorhanden so wird dieser als Antwort in etwa folgendes senden:
HTTP/1.1 200 OK
Date: Thu, 25 Nov 2010 00:53:15 GMT
Server: Apache/2.2.16
Content-Length: 100
Connection: close
Content-Type: text/html
<html>
<head><title>Beispiel-Seite</title></head>
<body>
Eine tolle Webseite !!
</body>
</html>
Man sieht deutlich den HTTP-Header welcher mit einer Leerzeile abgeschlossen ist und den darauf folgenden Daten-Teil der angeforderten Webseite. Auch hier gucken wir uns die Zeilen des Headers nochmal einzeln an:
- Zeile 1: Meine Antwort folgt der HTTP-v1.1 Spezifikation und die Anfrage wurde korrekt bearbeitet (Statuscode 200).
- Zeile 2: Das aktuelle Datum lautet Donnerstag, 25. Nov 2010, 00:53…
- Zeile 3: Ich bin ein Apache-HTTP-Server in der Version 2.2.16
- Zeile 4: Die nach dem Header folgenden Daten haben eine Länge von 100 Byte
- Zeile 5: Die Verbindung wird nach dem Senden der Antwort geschlossen.
- Zeile 6: Die nach dem Header folgenden Daten sind vom Typ Text/HTML
Hat der Browser die Antwort empfangen so ist die Abfrage der Webseite abgeschlossen. Der Browser wird nun die Text/HTML-Daten parsen und die Seite anzeigen. Wie man sieht passiert nichts mystisches wenn wir eine Webseite ansurfen. Browser und Webserver “reden” miteinander und können sich auch verstehen… dank dem HTTP-Protokoll.
GET, POST und andere Methoden:
An dieser Stelle möchte ich kurz auf die HTTP-Methoden eingehen. Im obigen Beispiel wurde für die Abfrage des Servers die Methode “GET” verwendet. Dies ist eine der beiden häufigsten Methoden bei der Abfrage von Dokumenten bzw. Webseiten. Bei der Methode GET werden evtl. für die Abfrage nötige Parameter, so wie wir es auch oft in der Adresszeile unseres Browsers sehen, mit einem “?” getrennt an das angeforderte Dokument angehängt. Das sieht dann z.B. so aus:
GET /beispielseite.php?parameter1=08¶meter2=15 HTTP/1.1
...
Diese Art der Parameter-Übergabe hat aber den Nachteil daß sie nicht zu lang werden sollte (man sagt 255 Zeichen). Größere Datenblöcke, die bei einer Seiten-Anforderung an einen Webserver übergeben werden sollen (z.B. ein 1000 Zeichen langer Blog-Text der nach dem Schreiben zum Server gesendet wird), fallen hier also raus. In solchen Fällen bedient man sich der Methode “POST”. Hier können quasi unbegrenzt große Parameter an den Server übertragen werden da die Daten hier nicht im Header sondern im Daten-Teil der HTTP Server-Anfrage übertragen werden. Und das könnte dann z.B. so aussehen:
POST /beispielseite.php HTTP/1.1 Host: www.meine-domain.tld User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 Content-Type: application/x-www-form-urlencoded Content-Length: 27 Connection: closeparameter1=08¶meter2=15
Wie man schön erkennen kann folgt diese HTTP-Anfrage dem üblichen Muster: “Header -Leerzeile – Daten“. Da die übergebenen Daten nun nicht mehr im Header stehen sondern im Datenteil, können diese nun wesentlich größer sein. Üblicher Weise wird diese Methode (POST) bei Web-Formularen eingesetzt. Wer sich also schon immer gewundert hat das nach dem Absenden eines Formulars an der Angezeigten URL keine Parameter hängen, der weiß nun warum. Zur Sicherheit will ich aber noch erwähnen das auch bei einer POST-Anfrage Parameter im Header zulässig sind.
Methode POST in einem Formular
Es gibt noch weitere HTTP-Methoden auf die ich aber nicht näher eingehen möchte, weil das dieses Tutorial eindeutig sprengen würde. Neben GET und POST gibt es noch HEAD, PUT, DELETE, TRACE, OPTIONS, CONNECT und weitere z.B. zu WebDAV gehörende Methoden. Nur damit ich sie mal erwähnt habe.
Noch mehr Header!
Die HTTP-Header die ich im eben gezeigten Beispiel aufgeführt habe sind mehr oder weniger typisch und umfassen alles was für einen Seitenabruf nötig ist. In der Praxis allerdings packen viele Server noch weitere Informationen in den Header. PHP z.B. verewigt sich gerne mit einer Header-Zeile die so aussehen könnte (siehe auch den Artikel “PHP sicher machen” Punkt “expose_php = Off“):
X-Powered-By: PHP/5.2.6
Auch wenn eine Webseite Cookies verwendet kann man diese im HTTP-Header entdecken:
Set-Cookie: PHPSESSID=b3f5a09dac699b866138983797882f96; path=/
Es ist durchaus interessant zu sehen was ein Server so alles im HTTP-Header sendet. Und damit das jeder mal selbst beobachten kann habe ich fix ein kleines Script zusammengeschustert, mit dem ihr die HTTP-Header beliebiger Webserver zu sehen bekommt. Ihr könnt es hier runter laden: HTTP-Header Anzeige-Script.
Ihr müsst das ZIP-File nur entpacken und bekommt dann das Script “get-http-header.php”. Alles was ihr jetzt noch braucht ist ein bisschen Webspace und PHP. Dann Script hochladen, ansurfen und fertig.
Script zum Anzeigen der HTTP-Header
Jetzt könnt ihr eine beliebige URL, gerne auch mit Parametern, in das Formular eingeben, absenden und “schwups”, bekommt ihr den HTTP-Header der Server-Antwort zu sehen.
Der HTTP-Header vom Server wird angezeigt.
Versucht doch mal die “üblichen Verdächtigen” einzugeben… google.de, wikipedia.de, webmaster-imho.de 
…vergesst nicht das “http://” am Anfang. Versucht auch mal eine nicht existierende Seite einzugeben, z.B. “http://www.wikipedia.de/gagaga.html“. Der Server antwortet dann korrekter Weise mit dem Statuscode 404 (Not Found):
HTTP/1.1 404 Not Found
Date: Thu, 25 Nov 2010 03:35:33 GMT
Server: Apache/2.2.16
Content...
...usw.
Beispiel Umleitung einer Webseite:
Ich will noch ein zweites Beispiel aufführen welches schön verdeutlicht wie ein Browser HTTP-Statuscodes auswertet und darauf reagiert. Nehmen wir an eine Webseite ist auf eine andere Domain umgezogen und der Webmaster will alle Besucher (und Suchmaschinen) die noch die alte URL aufrufen auf die neue URL umleiten. Also wird der Webmaster auf dem alten Server eine 301-Umleitung einrichten. Die HTTP-Kommunikation zwischen Browser und Webserver würde nun in etwa so aussehen:
GET /beispielseite.html HTTP/1.1
Host: www.alte-domain.tld
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Connection: close
Wie man sieht fordert der Browser die alte URL “http://www.alte-domain.tld/beispielseite.html” an. Der Webserver antwortet nun z.B.:
HTTP/1.1 301 Moved PermanentlyDate: Thu, 25 Nov 2010 21:53:01 GMTLocation: http://www.neue-domain.tld/beispielseite.htmlServer: Apache/2.2.16 Content-Length: 22 Connection: close Content-Type: text/html
Man kann deutlich erkennen daß der Server mit einem 301-Statuscode antwortet. Und wie wir alle wissen bedeutet Statuscode 301 nichts anderes als daß das angeforderte Dokument dauerhaft auf einer anderen Adresse zu finden ist (siehe HTTP-Statuscodes Tutorial Teil-1), oder kurz: “Moved Permanently“. Aber eine 301-Umleitung wäre ja nicht komplett wenn uns der Server nicht auch mitteilen würde wie die neue Adresse lautet. Und das tut er auch, und zwar in Zeile 3 des Header. Dort steht: “Location: http://www.neue-domain.tld/beispielseite.html“. Das ist der so genannte “Location-Header”. Den Rest des Headers kennen wir ja schon. Der Browser hat nun alle Informationen um das alte Dokument an neuer Position zu finden:
GET /beispielseite.html HTTP/1.1
Host: www.neue-domain.tld
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Connection: closeDer Browser schickt also eine neue Anfrage, die ich sicher nicht weiter erklären muss, und bekommt nun das Dokument ausgeliefert:
HTTP/1.1 200 OK
Date: Thu, 25 Nov 2010 22:02:33 GMT
Server: Apache/2.2.16
Content-Length: 100
Connection: close
Content-Type: text/html
<html>
<head><title>Beispiel-Seite</title></head>
<body>
Eine tolle Webseite !!
</body>
</html>
Biddeschön… 301-Umleitung perfekt! Wer möchte kann das auch live am “lebenden Objekt” beobachten. Tippt doch einfach mal “http://www.yahoo.de” in euren Browser ein. Wo kommt ihr raus? Richtig… bei “http://de.yahoo.com“. Das ist genau so eine 301-Weiterleitung. Und nun gebt das Gleiche mal in das HTTP-Header Anzeige-Script ein… Ha! Ist doch mal schön zu sehen was sonst nur im verborgenen geschieht.
Is ja einfach so’n HTTP-Protokoll…!
Sag ich doch! Im Grunde ist das wie bei uns Menschen, wenn man die selbe Sprache spricht dann klappt die Zusammenarbeit. Und da wir ja nun alle fließend HTTP sprechen, können wir dies auch anwenden und für unsere Zwecke nutzen. Für uns Webmaster geht das natürlich am besten mit einer Scriptsprache wie PHP. Wir können selber HTTP-Header erzeugen und senden oder aber Dokumente auf anderen Servern abfragen und deren Header korrekt auswerten. Aber wie man das am besten umsetzt, welche Fehler man machen kann und auf was man sonst noch achten muss, darum wird es im dritten und letzten Teil des HTTP-Tutorial gehen.
Links zum Thema HTTP-Protokoll:
Ein Link zum W3C ist in Sachen HTTP-Protokoll ja fast schon Pflicht. Von dort aus ist es dann nur noch ein Klick zur HTTP-Spezifikation nach RFC 2616. Das W3C ist übrigens das “Gremium zur Standardisierung der das World Wide Web betreffenden Techniken“, wie die Wikipedia schreibt. Und wenn wir schon bei der Wikipedia sind, dort gibt es natürlich auch einen informativen Artikel zum HTTP-Protokoll.
Buchempfehlung:
Wie schon im ersten Teil erwähnt gibt es in Sachen HTTP-Protokoll recht wenig Buch-Material. Das schon etwas ältere “HTTP – kurz & gut
To Be Continued:
Dieses war der zweite Streich, doch beim dritten werd’ ihr bleich…
…soll heißen Teil 3 des HTTP-Tutorials folgt in wenigen Tagen.
Lehrreicher Post. Interessant, wenn man das Thema auch mal aus einem anderen Blickwinkel beschrieben lesen kann.
Danke für den Beitrag bin schon gespannt auf den 3ten teil