Netzwerke

HTTP (Hypertext Transfer Protocol) ist das Protokoll des World Wide Webs. Übertragen werden vor allem Dokumente, die in HTML kodiert sind.

Als Client arbeitet ein Browser wie Firefox, Chromium oder andere.
Als Server dient ein Rechner mit einem Web-Server wie Apache.

Der Standardport ist 80. Die Übertragung erfolgt unverschlüsselt. Die aktuelle Version von HTTP/2 und ist in RFC 7540 definiert.

Als verschlüsselte Variante steht HTTPS zur Verfügung, die standardmäßig den Port 443 verwendet.

Das Protokoll HTTP

Das Protokoll ist textbasiert. Das bedeutet, dass die Anfragen (Request) und Antworten (Response) im Klartext über die Leitung gehen.

Das Protokoll ist grundsätzlich statuslos. Das bedeutet, dass eine Sitzung nach der Antwort durch den Server endet. In seiner ursprünglichen Anwendung für den Austausch wissenschaftlicher Dokumente war das völlig ausreichend. In Zeiten von Online-Shops sind aber längere Sitzungen erforderlich. Das heißt, dass der Server mehrere Anfragen einem Client zuordnen können muss. Dies wird beispielsweise über Cookies realisiert.

Die URL

Eine URL besteht aus dem Hostname (oder dessen IP-Adresse) und durch einen Schrägstrich getrennt das gewünschte Dokument, das ggf. durch einen Pfad spezifiziert wird. Optional kann durch einen Doppelpunkt angehängt ein Port spezifiziert werden.

Leerzeichen und Sonderzeichen dürfen in der URL nicht auftreten. Werden sie in den Parametern dennoch benötigt, werden Leerzeichen beispielsweise durch %20 dargestellt. Andere Zeichen werden durch eine URL-Codierung umgesetzt, die von der Zeichencodierung abhängig ist.

HTTP Request-Methoden

Das HTTP-Protokoll kannte in der Version 1.0 die Befehle GET, HEAD und POST. Die Version 1.1 brachte noch PUT und DELETE hinzu.

GET: Hole eine Datei (Dokument) vom Server. Dabei übergibt GET eine URL.Die URL kann um Anfrageparameter ergänzt sein, die mit einem Fragezeichen abgetrennt, angehängt werden. Die meisten Anfragen dürften unter diese Kategorie fallen.
POST: Sende Daten an den Server. Typischerweise sind dies Formular-Inhalte. Sie werden als Wertepaare aus der FORM eines HTML-Dokuments erstellt. Die Datenmenge ist weitgehend unbegrenzt und ist nur verschlüsselt, wenn als Protokoll HTTPS verwendet wird. Mit den übergebenen Daten können Server-Ressourcen angelegt oder verändert werden.
HEAD: Holt nicht die komplette Datei, sondern nur den HEAD-Anteil.
PUT dient vor allem zum Hochladen von Dateien. Die URL gibt das Ziel an. Ist unter der URL bereits eine Datei vorhanden, wird sie überschrieben.
DELETE: Löschen einer Server-Ressource.
CONNECT: Richte einen SSL-Tunnel ein.

Aufbau eines HTTP-Befehls

Eine Request beginnt mit der Zeile des Befehls. Beispielsweise lautet diese für einen GET der Datei index.htm folgendermaßen:

GET /index.htm HTP/1.1

Der Aufbau ist:

Befehl Leerzeichen URL Leerzeichen Version CR+LF

Alle Zeilen des Befehls werden mit CR-LF abgeschlossen.

Der Befehl GET besitzt nur einen HEAD, keinen BODY. Darum müssen eventuelle Parameter in der URL untergebracht werden. Das hat zur Konsequenz, dass diese Parameter nicht verschlüsselt werden können.

Der Head enthält allerdings durchaus weitere Informationen. Darin steht beispielsweise der Browser (User-Agent) oder die Sprache, die der Client bevorzugt (Accept-language). Durch einen Doppelpunkt getrennt werden die Inhalte übermittelt.

GET-Anfrage

Der Client sendet zunächst eine Befehlszeile mit dem folgenden Aufbau an den Server:

Das Schlüsselwort GET
(optional) Der Pfad zur Datei
(optional) Ein Fragezeichen, wenn Parameter folgen
(optional) Parameterangaben, die untereinander durch & separiert sind:
- Variable
- Gleichheitszeichen
- Wert
Protokollangabe mit Version, beispielsweise: HTTP/1.1

Der Request-Header der GET-Anfrage übermittelt folgende Informationen an den Server:

Host: Adressat
User-Agent: Mozilla etc, auch Plattform
Accept: MIME-Formate, mehrere Angaben sind möglich.
Accept-Language: Sprache
Accept-Encoding: gzip
Accept-Charset: ISO-8859-1 utf-8
Keep-Alive: 300

Im Anschluss an das Senden der Anfrage, wartet der Client auf die Antwort des Servers.

POST-Anfrage

Eine POST-Anfrage folgt der gleichen Struktur wie eine GET-Anfrage. Allerdings sendet POST keine Parameter per URL. Die Parameter werden im Message Body (Payload) transportiert.

Auf diese Weise sind die Paramter in ihrem Umfang nicht beschränkt.
Die Parameter werden im BODY transportiert. Dieser ist bei HTTPS verschlüsselt. Dagegen ist die URL nie verschlüsselt.
Allerdings lassen sich auf POST-Anfragen keine Lesezeichen setzen. Bei GET-Anfragen funktioniert das.

Die GET-Anfrage ist dafür gedacht, Anfragen zu stellen, die keine Änderungen an den Server-Ressourcen verursachen. Die Parameter beschreiben lediglich die angeforderten Daten. POST-Parameter sind dafür gedacht, Server-Ressourcen zu ändern.

HTTP Response

Die erste Zeile der Antwort des Server ist der Status-Code. Er folgt dem Aufbau:

Protokoll Leerzeichen Nummer Leerzeichen Status CR+LF

Beispielsweise ist eine positive Antwort:

HTTP/1.1 200 OK

HTTP-Status-Codes

Der Server antwortet auf Anfragen mit einem Status-Code in Form einer dreistelligen Zahl.

Basis	Zahlencode	Bedeutung
1xx		Informativ
2xx		Erfolgreich
	200	OK
	201	Created
	202	Accepted
	204	No Content. Anfrage ok, aber kein neuer Inhalt
3xx		Es sind weitere Aktionen erforderlich
	300	Mehrere Auswahlmöglichkeiten
	301	Permanent auf anderer URL
	302	Temporär auf anderer URL
	304	Inhalt ist unverändert
4xx		Fehler des Client
	400	Fehlerhafte Anfrage, etwa ungültige URL
	401	Nicht authorisiert
	403	Verboten
	404	Nicht gefunden
5xx		Fehler des Servers
	500	Interner Serverfehler
	501	Nicht implementiert
	502	Falsches Gateway (Proxy-Anwendung)
	503	Server ist überlastet
	505	HTTP-Version nicht unterstützt

Die Headerzeilen liefern zusätzliche Informationen wie Webserver (Server) und dessen Version.

Nach dem Header folgt der eigentliche Dateninhalt, die sogenannte Payload. Auf einen GET ist dies typischerweise ein HTML-Dokument.

Das HTTP-Paket

Methode (GET, POST, etc)
Leerzeichen
Status-Code (beispielsweise URL)
Leerzeichen
Status-Inhalt (beispielsweise Version)
Carriage Return und Line Feed (dez: 13 10)
Header-Zeilen (mehrfach)
- Header-Feld-Name
- Doppelpunkt Leerzeichen
- Inhalt
- Carriage Return und Line Feed (dez: 13 10)
Carriage Return und Line Feed (dez: 13 10)
Daten

Unterschiede zwischen HTTP/1.0 und 1.1

HTTP/1.1 erlaubt mehr als 1 Objekt pro Anfrage und stellt damit den Übergang von non-persistent nach persistant dar.

HTTP/1.1 ermöglicht Caching. Der Server meldet modified contents über ein ETag (Beispielsweise x234dff) und max-age (beispielsiweiese (max-age=120). Wendet sich der Client mit der gleicher ETag innerhalb der max-age, meldet sich der Server mit dem Status 304 ohne Payload.

Authentifizierung

Wenn Sie in einem Verzeichnis Ihrer Web-Präsenz die Datei .htaccess hinterlegen, können Sie eine Anmeldung des Benutzers erzwingen.

Es erscheint eine Dialogbox, die Benutzername und Passwort erfragt und mit der in der .htaccess hinterlegten Passwortdatei abgleicht. Jene legt auch fest, auf welche Art (AuthType) kommuniziert wird.

Basic: Das Passwort wird mit Base64 kodiert und ist damit leicht einsehbar.
Digest: Das Passwort wird (im Allgemeinen mit MD5) verschlüsselt und kann entsprechend nicht einfach eingesehen werden.

Digest Access Authentication

RFC 2069, 2617, 7235

Ablauf

Der Browser hat eine Seite mit GET angefordert, die in der Datei .htaccess durch eine Digest Authorisation geschützt ist. Darin liegt das durch die Hashfunktion md5 verschlüsselte Passwort und der Benutzer im Klartext vor.

Der Server antwortet mit einer i401-Unauthorized-Antwort. Darin übermittelt er eine nonce, eine zufällige Zahl, die nur einmal verwendet wird.
Der Client ermittelt einen Hashwert (MD5) aus Benutzer, nonce und Passwort.
Der Server prüft, ob das Passwort zu dem hinterlegten passt.

Understanding HTTP Digest Access Authentication

Web Caching

Erweiterung durch HTTP 1.1.

Der Browser speichert zuvor angefragte Seiten mit ihrem letzten Zugriff. An den Web-Server ergeht eine GET-Anfrage. Im Header-Feld If-Modified-Since wird das Datum übermittelt.

Der Server antwortet mit 304 Not Modified ohne die Seite, da diese dem Client ja vorliegt oder mit einer normalen 200 OK-Antwort mit der Seite, wenn die vorliegende Seite neuer ist.

Wikipedia: HTTP Caching

Cookies

HTTP ist eigentlich statuslos. Das bedeutet, dass eine Anfrage nicht mehr weiß, was in der vorigen Anfrage geschehen ist. Für verlinkte Dokumente ist das ausreichend, aber bei einem Shop will der Benutzer seinen Einkaufswagen behalten, wenn er auf die nächste Seite wechselt.

Cookies sind kleine Dateien, die der Server beim Eröffnen der Shopping-Tour an den Client (Browser) im Header-Feld set-cookie sendet. Der Cookie enthält den (eindeutigen) Namen des Shops und eine eindeutige Sitzungsnummer. Der Client speichert das Cookie (Shopname und Sitzungsnummer) in seinem lokalen Cache. Bei einem Aufruf einer anderen Seite des Shops fragt der Server, ob ein Cookie vorliegt und ermittelt anhand der Sitzungsnummer den Warenkorb des Benutzers.

Probleme ergeben sich, wenn Cookies an Server weitergegeben werden, die gar nicht der Shop-URL entsprechen, weil dieser Server dann nachvollziehen kann, welchen Shop der Client besucht hat.

Wikipedia: HTTP Cookie