HTTP feiert einen runden Geburtstag – Zeit, zu erklären, was es eigentlich genau tut

Da Sie den vorliegenden Blog-Beitrag lesen, haben Sie es vor Kurzem erst das letzte Mal genutzt: Das «Hypertext Transfer Protocol» kurz HTTP. Auch wenn es heutzutage nicht (mehr) explizit in die Adresszeile des Browsers eingegeben werden muss, stehen die vier Buchstaben – manchmal mit und manchmal ohne einem zusätzlichen «s» – gefolgt von einem Doppelpunkt und zwei Slashes vor jeder WWW-Adresse. Doch was ist eigentlich «HTTP»? Wozu braucht man es und wie funktioniert es?

Da HTTP dieses Jahr seinen 25. Geburtstag feiert – die erste Version 0.9 wurde 1991 definiert – und ich gerade im Restaurant-Wagen des Intercity von Zürich nach Bern sitze, finde ich es an der Zeit, einmal auch in puncto Internet-Protokollen «Schluss mit On-Laien» zu machen.

Was ist eigentlich ein Protokoll?

Eigentlich verwenden wir tagtäglich Protokolle, auch wenn wir nicht gerade im Internet surfen: Wir halten uns bei gewissen Dingen wie z.B. dem Telefonieren an einen gemeinsam vereinbarten, vordefinierten Ablauf. Ich rufe eine bestimmte Nummer an, warte auf den Klingelton, wenn das Besetzt-Zeichen kommt, versuche ich es später noch einmal. Wenn jemand am anderen Ende der Leitung den Anruf annimmt, sagt er oder sie erst einmal den Namen, damit ich weiss, ob ich beim richtigen Empfänger gelandet bin, dann sage ich meinen Namen, damit die angerufene Person weiss, wer ich bin usw.

Oder anders herum: Man könnte notieren, was bei einen Telefonanruf so alles gemacht wird. Dann würde man es protokollieren, ein Protokoll erstellen. Das Wort «Protokoll» ist uns also gar nicht so ungeläufig.

Auch im Speisewagen halte ich mich an das Protokoll und winke dem Kellner.

«Die Speisekarte bitte» – der erste Kontakt mit einem Webserver

Wenn ich im WWW surfe, braucht es auch ein Protokoll, damit mein Browser (der gerne eine Website anzeigen würde) und der Web-Server (der die Website bereit hält) sauber kommunizieren können, damit sie wissen, wie sie miteinander zu «reden» haben. Wer spricht zuerst? Wer darf wann wie antworten?

Meistens startet die Kommunikation mit einem Webserver, indem ich die WWW-Adresse des Servers in meinen Browser eingebe. Ich tippe also z.B. «www.elvetino.ch» und erhalte die sogenannte Homepage, die Übersichts-Seite des Servers:

Spannenderweise erhalte ich dieselbe Seite, wenn ich explizit «www.elvetino.ch/index.php» eingebe. Der Server weiss also, welche Seite er als Erstes zu liefern hat, auch wenn ich nicht explizit angebe, welche ich gerne hätte. In etwa so, wie ein Kellner weiss, dass man gerne die Speisekarte hätte, wenn man das erste Mal etwas von ihm will, aber noch nicht genau weiss, was.

Tatsächlich versteht mich der Kellner im Speisewagen wortlos – ich habe ja nur gewunken – und bringt mir eine Speisekarte.

GET – etwas bestellen

Das Hypertext-Transfer-Protokoll kennt verschiedene sogenannte Anfrage-Methoden. Eine davon – die wohl am häufigsten verwendete – heisst GET. Sie dient dazu, etwas vom Server zu bestellen.

«Liebes Restaurant, ich (der Gast an Tisch 13) hätte gerne ein Bier!» schreibt sich in der Adresszeile des Browsers ungefähr so:

http://www.restaurant.ch/bier.html

Das können wir uns als Benutzer recht gut merken. Normalerweise arbeiten Computersysteme im Hintergrund aber komplizierter, als dass wir es uns gut merken könnten. In HTTP würde die Bier-Bestellung nämlich etwa so aussehen:

GET /bier.html HTTP/1.1  
Host: www.restaurant.ch

Wir verstehen aber in etwa, was da so über das Internet geschickt wird.

Request und Response – wer fragt, bekommt eine Antwort

Auf unsere Anfrage (den sogenannten Request) folgt dann vom Server eine Antwort: die sogenannte Response.

Z.B. bringt uns der Kellner das bestellte Bier. Alles ist in bester Ordnung. Die Response vom Server sieht dann etwa so aus:

HTTP/1.1 200 OK
Server: SBB-Speisewagen
Content-Lenght: 3dl
Content-Language: de
Connection: close
Content-Type: Getränk/Bier

Jede Antwort vom Server hat einen Code. Hier ist es die 200 in der ersten Zeile der Antwort. Codes, die mit 2 beginnen, stehen für eine erfolgreiche Operation.

Aber es gibt (leider) aber auch andere Status-Codes:

• Status-Codes, die mit 1 beginnen: Informationen wie z.B. «Wir haben ihre Bestellung erhalten, es dauert aber noch ein bisschen, bis das Bier kommt. Haben Sie bitte etwas Geduld.»
• Status-Code, die mit 3 beginnen: Umleitungen wie z.B. «Da sie eine ‘Stange’ bestellt haben, bringen wir Ihnen gerne ein ‘Bier 3dl’.»
• Status-Code, die mit 4 beginnen: Fehler beim Gast
  • z.B. der 404-Fehler (Seite wurde nicht gefunden): «Sie haben etwas bestellt, das wir nicht haben.»
  • Oder der 403-Fehler (Zugriff nicht erlaubt): «Sie haben etwas bestellt, das Sie nicht dürfen, da Bier nur an Über-16-Jährige ausgeschenkt wird.»
• Status-Code, die mit 5 beginnen: Fehler beim Restaurant wie z.B. der 501-Fehler «Unsere Bier-Zapfanlage ist gerade defekt, sorry!»

Request-Methoden – was man als Gast so alles anfragen kann

Jetzt kennen wir GET als jene Methode, mit der wir eine Datei auf einem Server anfragen können. Aber, wie auch im Restaurant, gibt es noch andere Anfragen. Hier ein Auszug:

• POST: Mit POST kann ich nicht nur etwas anfragen, sondern auch gleich noch dem Kellner etwas in die Hand drücken, das er mitnehmen soll. Z.B. frage ich nach der Rechnung und gebe dem Kellner gleich schon etwas Geld in die Hand. Im WWW benutzen wir das sehr oft: Wenn wir Daten in ein Formular eingeben, werden diese Daten zusätzlich zur Anfrage, welche Datei erscheinen soll, mitgeschickt. Wenn man Bilder oder andere Dateien irgendwohin hochlädt, werden die Dateien ebenso mitgeschickt.
• HEAD: Diese Methode ist vergleichbar mit der Frage: «Haben Sie noch Bier?». Der Kellner schaut dann kurz nach und meldet, ob er noch Bier hat oder nicht – aber er bringt keines.
• PUT: Normalerweise ist PUT auf WWW-Servern deaktiviert, denn mit PUT könnte ich als Gast sagen: «Liebes Restaurant, hier haben sie ein neues Getränk von mir.» Und dieses neue Getränk würde ab sofort für alle anderen Gäste zur Verfügung stehen. Die wenigsten Restaurants möchten das – Web-Server auch nicht unbedingt.
• DELETE: Ist ebenfalls eher selten aktiviert, denn welches Restaurant lässt sich schon von einem Gast sagen: «Ab jetzt haben sie kein Bier mehr!»
• TRACE: Ist vergleichbar mit dem Wunsch, dass mir der Kellner doch bitte meine Bestellung wiederholen soll, damit ich überprüfen kann, ob er sie richtig verstanden hat. Manchmal kommt ja auch der Kellner nach der Bestellung nochmals vorbei und fragt nach, ob er meine Bestellung auch korrekt bis zur Theke mitgenommen hat.

HTTPS – Geheimsprache sprechen

Um den Blog-Artikel abzurunden verliere ich nun noch ein paar Worte zu «HTTPS», in dem das «S» für «secure» bzw. «sicher» steht.

Wenn man z.B. die Digicomp Website unter www.digicomp.ch öffnet, sieht man vor der WWW-Adresse ein «https»:

Das kleine Schloss davor zeigt auch grafisch an, dass ich in diesem Restaurant mit dem Kellner in codierter Geheimsprache spreche. Würde ich ganz normal mit dem Kellner sprechen, könnten alle anderen Gäste im Restaurant ja mithören und würden verstehen, was ich anfrage. Mit HTTPS kann zwar mitgehört werden, aber keiner versteht die Geheimsprache. Das ist vor allem für Web-Applikationen, auf denen sensible Daten ausgetauscht werden – wie z.B. E-Banking – sehr wichtig. Digicomp stellt mit HTTPS einfach sicher, dass die persönliche Information, für welche Kurse man sich interessiert und für welche man sich anmeldet, nicht einfach so unverschlüsselt mitgehört werden.

Zum Schluss

Jetzt, wo Sie etwas mehr über HTTP wissen und es sogar halbwegs verstehen, schlage ich vor, dass Sie entweder …

GET /anderer-blog-beitrag.html HTTP/1.1   
Host: www.digicomp.ch

… oder unten …

POST /kommentar-hinterlassen.html HTTP/1.1   
Host: www.digicomp.ch
Content-Length: 30
Von Ihnen verfasster Kommentar

… oder ganz einfach den Feierabend geniessen mit …

GET Bier HTTP/1.1 
Host: Kühlschrank

Prost!