HTTP/Einsteiger-Tutorial

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Bei HTTP handelt es sich um eine Art Sprache, in der ein Webserver und ein Browser miteinander kommunizieren. Diese Kommunikation erfolgt nach einem festgelegten Schema, das man auch "Protokoll" nennt. HTTP ist also ein Protokoll, daher auch der Name "HyperText Transport Protocol".

Das Wissen um HTTP und wie es im Einzelnen funktioniert, ist für diejenigen wichtig, die mit clientseitigen Scriptsprachen wie z. B. JavaScript, oder mit serverseitigen Scriptsprachen wie ASP.Net, Java, Perl, PHP, Python oder dergleichen Datentransfers programmieren wollen.

Rein für das Erstellen von HTML-Dokumenten oder ihre Ausgestaltung mittels CSS spielt das Wissen um HTTP keine Rolle.

Hinweis:
Wenn hier und im Folgenden von "Browser" und "Webserver" geschrieben wird, ist damit prinzipiell "Client" und "Server" zu verstehen, denn das HTTP Protokoll wird nicht nur bei der Kommunikation von Browsern mit Webservern verwendet.
Beachten Sie: Sollen ergänzende Inhalte (Bilder, Layout-Dateien, etc.) in ein mit HTTPS ausgeliefertes Dokument eingebunden werden, müssen diese ihrerseits ebenfalls via HTTPS geladen werden. Dazu notieren Sie nach Möglichkeit protokoll-relative URIs.

Request und Response

Kommunikation per HTTP geschieht immer in dieser Reihenfolge:

  1. Request
  2. Response

Ruft ein Seitenbesucher mit seinem Browser eine Internetseite auf, so sendet der Browser eine Anfrage ("Request", englisch für Bitte/Wunsch/Anfrage) an den Webserver, die von diesem mit einer "Response" (englisch für Antwort/Erwiderung/Reaktion) beantwortet wird. Dabei senden sich Browser und Webserver gegenseitig Textdateien zu, in denen nach den Regeln von HTTP diverse Informationen enthalten sind.

Beispiel für einen erfolgreichen Seitenaufruf

Hier sehen wir die (verkürzte) Textdatei, welche der Browser an den Webserver sendet, um die Startseite dieses Wikis zu erhalten:

Beispiel 
GET /wiki/Startseite HTTP/1.1
Host: wiki.selfhtml.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
In der ersten Zeile sehen wir auch schon gleich das Wichtigste: Die Pfadangabe /wiki/Startseite (wichtig: absolut, aber ohne Hostnamen) und das verwendete Protokoll (HTTP Version 1.1). Der Webserver, von dem die Daten abgerufen werden sollen, steht in einer späteren (hier in der zweiten) Zeile nach dem Wort "Host" und dem trennenden Doppelpunkt. Wer sich jetzt wundert, warum man den Hostnamen gesondert angeben muss, sei daran erinnert, dass auf ein und demselben Webserver mehrere Internetpräsenzen gehostet werden könnten, welche durch den Hostnamen unterschieden werden.
Man kann sehen, dass in der Anfrage Daten enthalten sind, was der Browser an möglichen technischen Voraussetzungen mitbringt, sodass der Server seine Antwort entsprechend formulieren kann, damit der Browser sie auch versteht. Dazu gehören die Zeilen, die mit "Accept" beginnen.

Der Webserver sendet die folgende (auch verkürzte) Textdatei als Antwort:

Beispiel 
HTTP/1.1 200 OK
Date: Mon, 28 Aug 2017 09:02:55 GMT
Content-language: de-formal
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Last-Modified: Tue, 22 Aug 2017 08:15:31 GMT
Content-Encoding: gzip
Content-Length: 7986
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html lang="de" dir="ltr" class="client-nojs">
<head>
Bei der Response steht in der ersten Zeile, dass der Aufruf korrekt beantwortet werden konnte (man beachte die Zahl 200, ein HTTP-Statuscode, der für das nachfolgend notierte "OK" steht). Die weiteren Zeilen enthalten Angaben, die der Webserver zu dem Dokument macht, wie z.B. die im Dokument verwendete natürliche Sprache (hier Deutsch, genauer "Schriftdeutsch"), welcher Datentyp (hier HTML), wie die Textdaten enkodiert sind (hier UTF-8), wie viele Bytes die Datei lang ist und ab wann der Inhalt des Dokuments als veraltet zu betrachten ist. Nach einer Leerzeile beginnt dann der eigentliche HTML-Code, also der für die anzuzeigende Seite eigentliche Inhalt.

Bei der Response kann man schön sehen wie HTTP aufgebaut ist:

  1. HTTP-Headerdaten
  2. Leerzeile
  3. Nutzdaten (auch "Payload" genannt)

Da der Webserver grundsätzlich "Daten" zurück gibt, enthält eine HTTP-Response immer Nutzdaten – es sei denn, jemand hat den Server absichtlich oder wegen eines Fehlers eine leere Datei senden lassen, sodass die Nutzdaten nach der Leerzeile fehlen.

Beachten Sie: Achten Sie darauf, dass Ihr Webserver nur dann einen 200-er Statuscode zurückgibt, wenn die Antwort auch wirklich korrekt ist. Webseiten, die von Programmen erzeugt werden (z.B. mit PHP), sollten für technische Fehlermeldungen einen der 400-er oder 500-er Statuscodes verwenden. Der Grund dafür ist, dass eine Suchmaschine beim Lesen Ihrer Seite den Statuscode als Hinweis darauf nimmt, ob sie eine gültige Seite gefunden hat, die in den Suchindex kann. Eine technische Fehlermeldung sollte aber kein Suchergebnis in einer Suchmaschine sein.

Beispiel für einen gescheiterten Seitenaufruf

Hier wieder der (verkürzte) Aufruf:

Beispiel 
GET /wiki/Quatsch_mit_So%C3%9Fe HTTP/1.1
Host: wiki.selfhtml.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br

Es wird also die Seite /wiki/Quatsch_mit_Soße angefragt, die es natürlich nicht gibt. Daher sehen die Response-Daten deutlich anders aus:

Beispiel 
HTTP/1.1 404 Not Found
Date: Mon, 28 Aug 2017 09:05:31 GMT
Content-language: de-formal
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html lang="de" dir="ltr" class="client-nojs">
<head>

Gleich in der ersten Zeile steht anstatt der Zahl 200, welche für den HTTP-Statuscode "OK" stand, eine 404. Der Statuscode 404 steht für "Not Found", also "nicht gefunden". Das ist insofern bemerkenswert, als dass ein anfragendes Programm schon alleine damit zufrieden sein könnte. Es kommen nun aber Angaben, dass das gesendete Dokument ein HTML-Dokument ist, welches in UTF-8 kodierte Nutzdaten enthält. Zeigt der Browser nun dieses Dokument an, so sehen wir die Fehlermeldung des Webservers als Seite im Browser.

Wenn Sie einen eigenen Webserver betreiben wollen, ist hier eine Stelle, an der Sie möglicherweise Hand anlegen müssen. Denn die standardmäßigen Fehlerseiten der Webserver sind oftmals sehr ausführlich und verraten Dinge über Serverinterna, die Sie der Öffentlichkeit nicht unbedingt preisgeben möchten. Über eine eigene Antwortseite (bei Apache: ErrorDocument-Eintrag in der Konfiguration) können Sie für einzelne HTTP-Statuscodes dafür sorgen, dass der Anwender genau das erfährt, was er soll, und nicht mehr.

Content-Type für Datenformate

Gerade haben wir ein Beispiel für einen gescheiterten Seitenaufruf gesehen. Es wurde eine Seite angefragt, die es nicht gibt. Die vom Webserver mitgeschickte HTML-Datei, die eigentliche Fehlerseite des Webservers, hat uns nicht weiter verwundert, da wir ohnehin ein HTML-Dokument angefordert hatten. Was aber, wenn wir eigentlich eine Bilddatei laden wollten?

Beispiel 
GET /images/3/31/Hund.gif HTTP/1.1
Host: wiki.selfhtml.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate

Die Datei [/images/3/31/Hund.gif wiki.selfhtml.org/images/3/31/Hund.gif] existiert offensichtlich:

Beispiel 
HTTP/1.1 200 OK
Date: Mon, 28 Aug 2017 09:11:05 GMT
Last-Modified: Sun, 29 Jun 2014 07:39:50 GMT
Content-Length: 2268
Content-Type: image/gif

R0lGODlh0AC1ALMAAAAAAGZEM5lVIkRERLtmRLuIZqqIiMy7iLvM3d3d3d27mf/du///
Wieder sehen wir den Beginn der Nutzdaten wieder nach der Leerzeile. Die Bilddatei ist im GIF-Format, die Binärdaten werden in Textform (base64-kodiert) übertragen, da sich Browser und Webserver über HTTP ja ausschließlich Textdateien zusenden dürfen.

Was passiert aber, wenn die Bilddatei nicht vorhanden ist? Probieren wir es mit "Hund2.gif":

Beispiel 
GET /images/3/31/Hund2.gif HTTP/1.1
Host: wiki.selfhtml.org

Die Antwort enthält wenig überraschend wieder den Statuscode 404:

Beispiel 
HTTP/1.1 404 Not Found
Date: Mon, 28 Aug 2017 09:17:43 GMT
Last-Modified: Wed, 02 Aug 2017 09:59:51 GMT
Content-Length: 3919
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html>
<head>

Was aber überrascht, ist die Tatsache, dass wir wieder ein HTML-Dokument erhalten, anstatt einer Bilddatei. Die Fehlerseite des Servers kommt eben nicht als Bilddatei, sondern als HTML-Dokument. Und damit der Browser das richtig verarbeiten und anzeigen kann, achtet dieser auf die Header-Zeile mit "Content-Type", denn da steht, welches Datenformat der Server in seiner Antwort sendet. Sollte sich ein Spaßvogel die Mühe machen, die Fehlerseite als Bild umzusetzen, so würde der Browser korrekt ein Bild als "Seite" anzeigen, da er den Content-Type berücksichtigt. Jedoch hätte der Spaßvogel wenig Freude, wenn seine Besucher hilflos auf das Bild starren und letzten Endes seine Seite gefrustet für immer verlassen, anstatt eine hilfreiche Fehlerseite mit Suchfunktion und Links zu weiteren Möglichkeiten vorzufinden.

Hinter den Angaben im "Content-Type"-Header versteckt sich jeweils ein sogenannter Internet Media Type, also eine standardisierte Angabe zum Dateiformat für die Nutzdaten.

GET und POST

Bisher haben wir in den Header-Daten gleich in der ersten Zeile das Schlüsselwort "GET" gesehen, wenn der Browser eine Seite anfordert. Bei einem regulären Seitenaufruf ist die HTTP-Methode "GET" auch das übliche Vorgehen. Manchmal aber wollen wir an den Webserver Daten übertragen, wie z. B. bei einem Login-Formular. Dazu gibt es eine weitere Methode, nämlich "POST". Hier sendet der Browser nun neben seinen üblichen HTTP-Header-Zeilen auch Nutzdaten:

Beispiel 
POST /index.php?title=Spezial:Anmelden&returnto=Startseite HTTP/1.1
Host: wiki.selfhtml.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 225

wpName=Hans+im+Glück
wpPassword=streng-geheim
Die Nutzdaten, welche vom Browser an den Server gesendet werden, sind die Formularinhalte, die der Benutzer in seinem Browser in das Anmeldeformular eingegeben hat. Die "Namen" bzw. "Schlüssel" zwischen Anfang der Zeile und dem Gleichheitszeichen sind die Namen, die die jeweiligen Formulareingabefelder hatten. Hauptartikel: HTML/Tutorials/Formulare/Was ist ein Webformular?

Es gibt noch weitere HTTP-Methoden, deren Behandlung aber den Rahmen dieses Tutorials sprengen würden.

Siehe auch

Weblinks

Abgerufen von „http://wiki.selfhtml.org/index.php?title=HTTP/Einsteiger-Tutorial&oldid=97194“