Hypertext Transfer Protocol

Grundidee und Eigenschaften

Das Hypertext Transfer Protocol (HTTP) ist ein 1991 eingeführtes, zustandsloses Protokoll zur Datenübertragung über Rechnernetze. Es arbeitet auf der Anwendungsschicht, im ISO/OSI-Modell also auf Schicht 7. Hauptsächlich lädt es Webseiten aus dem World Wide Web in einen Browser, kann aber auch beliebige andere Dateien und Daten übertragen. HTTP ist unter anderem die Grundlage von WebDAV und wird für Webservices verwendet.

„Zustandslos“ bedeutet, dass der Server Informationen aus früheren Anfragen nicht automatisch behält. Anwendungen können dennoch Sitzungen verwalten, indem sie Sitzungsbezeichner verwenden und beispielsweise Cookies in den Headern übertragen. So lassen sich Benutzerkonten oder Warenkörbe einer Sitzung zuordnen.

HTTP verwendet standardmäßig Port 80 für unverschlüsselte und Port 443 für verschlüsselte Übertragungen. Bis HTTP/2 dient normalerweise TCP als zuverlässiges Transportprotokoll. HTTP/3 verwendet QUIC, das auf UDP aufbaut. Bei HTTP bis Version 2 können unverschlüsselte Inhalte grundsätzlich von durchlaufenen Rechnern und Routern gelesen werden. HTTPS schützt die Übertragung durch Verschlüsselung; HTTP/3 erzwingt über QUIC eine TLS-Kodierung.

HTTP wurde von der Internet Engineering Task Force (IETF) und dem World Wide Web Consortium (W3C) standardisiert. Die aktuelle Version HTTP/3 wurde im Juni 2022 als RFC 9114 veröffentlicht. Für die Weiterentwicklung ist die HTTP-Arbeitsgruppe HTTPbis der IETF zuständig.

Nachrichten und Ablauf

HTTP folgt gewöhnlich dem Prinzip von Anfrage und Antwort. Der Client, meist ein Browser, sendet eine Anfrage (Request) an einen Server. Der Server reagiert mit einer Antwort (Response). Beide Arten von Nachrichten bestehen aus einem Nachrichtenkopf (Header) und gegebenenfalls einem Nachrichtenrumpf (Body). Der Header enthält Angaben wie Inhaltstyp, Kodierung oder Länge; der Body enthält die eigentlichen Nutzdaten.

Beim Aufruf von http://www.example.net/infotext.html wird zunächst der Hostname www.example.net über DNS in eine IP-Adresse umgesetzt. Danach sendet der Browser über TCP an Port 80 beispielsweise:

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

GET fordert die Ressource /infotext.html an. Das in HTTP/1.1 erforderliche Host-Feld ermöglicht es, mehrere DNS-Namen unter derselben IP-Adresse zu unterscheiden; in HTTP/1.0 war es optional. Nicht erlaubte Zeichen werden %-kodiert. Weitere Header können etwa den Browser oder die gewünschte Sprache beschreiben. Jede Headerzeile endet mit <CR><LF>; eine ausschließlich aus <CR><LF> bestehende Leerzeile beendet den Header.

Eine erfolgreiche Antwort kann mit „HTTP/1.1 200 OK“ beginnen. Weitere Header nennen beispielsweise Server, Content-Length, Content-Language und Content-Type. Nach einer Leerzeile folgt der Inhalt. Das können HTML, Bilder, CSS oder JavaScript sein; grundsätzlich ist jedes Dateiformat möglich. Inhalte können auch dynamisch erzeugt werden und müssen nicht als physische Datei auf dem Server liegen. Kann die Anfrage nicht wie gewünscht erfüllt werden, sendet der Server einen passenden Statuscode und meist eine erklärende Meldung.

Versionen und technische Entwicklung

Die Grundlagen von HTTP, URL und HTML wurden ab 1989 von Tim Berners-Lee und seinem Team am CERN entwickelt. 1991 entstand HTTP 0.9.

HTTP/1.0 wurde im Mai 1996 als RFC 1945 veröffentlicht. Standardmäßig baut es für jede Anfrage eine neue TCP-Verbindung auf und schließt sie nach der Antwort. Eine HTML-Seite mit zehn eingebetteten Bildern benötigt daher insgesamt elf TCP-Verbindungen.

HTTP/1.1 erschien 1999 als RFC 2616. Wiederverwendbare, dauerhafte Verbindungen (persistent connections) und HTTP-Pipelining erlauben mehrere Anfragen und Antworten über dieselbe TCP-Verbindung. Das Beispiel mit einer HTML-Seite und zehn Bildern kommt dadurch mit einer Verbindung aus. Dies verkürzt die Ladezeit, weil neue TCP-Verbindungen anfangs durch den Slow-Start-Algorithmus langsam sind. Abgebrochene Übertragungen können außerdem fortgesetzt werden. HTTP/1.1 ergänzte unter anderem PUT zum Hochladen beziehungsweise Ersetzen, DELETE zum Löschen und TRACE zur Kontrolle des Übertragungswegs. Wegen Unklarheiten wurde die Spezifikation 2014 ohne neue Funktionen in sechs RFCs neu gefasst: RFC 7230 bis RFC 7235 behandeln Nachrichtensyntax und Routing, Semantik und Inhalt, bedingte Anfragen, Bereichsanfragen, Caching und Authentifizierung.

HTTP/2 wurde im Mai 2015 verabschiedet und durch RFC 7540 sowie RFC 7541 spezifiziert. Es blieb zu HTTP/1.1 abwärtskompatibel, optimierte aber die Übertragung. Multiplexing fasst mehrere Datenströme in einer Verbindung zusammen. Hinzu kommen binäre Kodierung, priorisierbare Streams, serverseitig angestoßene Übertragungen (Server Push) sowie die Kompression von Headern mit HPACK. Dadurch können Latenz und Belastung der Netzwerkhardware sinken. Eine verpflichtende TLS-Nutzung wurde nicht Teil des Standards, doch Google und Mozilla unterstützten HTTP/2 in ihren Browsern nur verschlüsselt.

HTTP/3 verwendet QUIC statt TCP. Bei TCP kann ein verlorenes Paket alle nachfolgenden Datenströme aufhalten, was Head-of-Line Blocking heißt. QUIC baut auf UDP auf, ergänzt aber Zuverlässigkeit und verbindungsorientierte Kommunikation. Es verwendet TLS 1.3, unterstützt mehrere getrennte Datenströme und blockiert bei einem Paketverlust nur die betroffenen Ströme. Außerdem soll die optimierte Verbindungsaushandlung die Latenz verringern. QUIC wurde 2021 standardisiert; im November 2018 erhielt HTTP über QUIC den Namen HTTP/3, das im Juni 2022 als RFC 9114 standardisiert wurde. HTTP/3 ist grundsätzlich verschlüsselt.

Anfragemethoden und Argumente

HTTP stellt verschiedene Anfragemethoden bereit:

• GET fordert eine durch einen URI bezeichnete Ressource an. Laut Standard soll GET nur Daten abrufen und keine Änderungen oder andere Auswirkungen auf dem Server auslösen.
• POST überträgt Daten im Nachrichtenrumpf zur Verarbeitung. Dadurch können Ressourcen entstehen oder verändert werden. POST-Daten werden im Allgemeinen nicht von Caches gespeichert.
• HEAD fordert nur dieselben Header wie GET an, aber keinen Nachrichtenrumpf. Damit lassen sich etwa Gültigkeit und Größe einer zwischengespeicherten Datei prüfen.
• PUT lädt eine Ressource an einen Ziel-URI hoch. Eine vorhandene Ressource wird ersetzt, andernfalls neu erstellt.
• PATCH verändert Teile eines vorhandenen Dokuments, ohne es vollständig wie PUT zu ersetzen. Die Methode wurde durch RFC 5789 spezifiziert.
• DELETE löscht eine Ressource.
• TRACE gibt die vom Server empfangene Anfrage zurück und hilft beim Debugging.
• OPTIONS nennt unterstützte Methoden und Merkmale.
• CONNECT wird von Proxyservern für SSL-Tunnel eingesetzt.

RESTful Web Services verwenden besonders GET, POST, PUT beziehungsweise PATCH und DELETE. WebDAV ergänzt unter anderem PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK und UNLOCK.

Argumente können per GET oder POST übertragen werden. Bei GET stehen sie in der URL und bleiben daher beim Speichern oder Weitergeben des Links erhalten. Nach einem ? folgen Name-Wert-Paare der Form Parametername=Parameterwert, meist durch & getrennt. Die Wikipedia-Suche nach „Katzen“ kann etwa „?search=Katzen&go=Artikel“ übertragen. Reservierte Zeichen werden als „%<Hex-Wert>“, Leerzeichen als „+“ URL-kodiert. Weil solche Parameter oft in der Browserhistorie landen, eignet sich GET nicht für persönliche Daten.

POST schreibt die Daten stattdessen in den Nachrichtenrumpf, sodass sie nicht in der URL erscheinen. Ein Formular kann beispielsweise mit dem Inhaltstyp application/x-www-form-urlencoded den Rumpf „search=Katzen&go=Artikel“ senden. POST eignet sich auch für große Datenmengen wie Bilder. In beiden Suchbeispielen kann der Server mit „302 Found“ und einem Location-Header auf die eigentliche Artikelseite umleiten; der Browser ruft anschließend die neue Adresse ab.

Statuscodes und Authentifizierung

Jede Serverantwort enthält einen HTTP-Statuscode. Seine erste Ziffer kennzeichnet die Art des Ergebnisses:

• 1xx liefert Informationen, während die Bearbeitung noch läuft.
• 2xx bezeichnet eine erfolgreiche Operation; häufig ist „200 OK“.
• 3xx verlangt weitere Schritte des Clients, etwa eine Umleitung zur Adresse im Location-Header. „302 Found“ ist ein Beispiel.
• 4xx bezeichnet einen Fehler im Verantwortungsbereich des Clients. „404 Not Found“ bedeutet, dass die angeforderte Ressource nicht existiert. „403“ verweigert den Zugriff, etwa auf vertrauliche oder nur per HTTPS erreichbare Dokumente.
• 5xx bezeichnet einen serverseitigen Fehler. „501“ bedeutet beispielsweise, dass dem Server nötige Funktionen zur Bearbeitung fehlen.

Benötigt eine Ressource Anmeldedaten, antwortet der Server mit „401 Unauthorized“ und dem Header WWW-Authenticate. Der Browser verwendet vorhandene Daten oder fragt Benutzername und Passwort ab. Bei Basic Authentication überträgt er „Benutzername:Passwort“ im Authorization-Header Base64-kodiert. Base64 ist keine kryptographische Absicherung; Basic Authentication gilt daher nur zusammen mit HTTPS als sicher.

Bei Digest Access Authentication sendet der Server zusätzlich eine zufällige Zeichenfolge, die Nonce. Der Browser bildet aus Benutzername, Passwort, Nonce, HTTP-Methode und URI einen Hashcode und sendet ihn mit Benutzername und Nonce zurück. Der Server vergleicht ihn mit seiner eigenen Prüfsumme. Die ursprünglichen Daten lassen sich aus dem Hashcode nicht rekonstruieren, und das Ergebnis unterscheidet sich bei jeder Anfrage.

Kompression und Webanwendungen

HTTP-Kompression verringert die übertragene Datenmenge. Der Client nennt im Header Accept-Encoding die Verfahren, die er verarbeiten kann, beispielsweise „gzip, deflate“. Der Server wählt ein unterstütztes Verfahren und nennt es in Content-Encoding. Besonders gut lassen sich textbasierte Formate wie HTML, XHTML, CSS, JavaScript, XML und JSON komprimieren. Bei bereits komprimierten Bild-, Audio- oder Videoformaten bringt eine erneute Kompression gewöhnlich keinen Nutzen. In Verbindung mit TLS kann Kompression allerdings den BREACH-Exploit ermöglichen, durch den die Verschlüsselung gebrochen werden kann.

HTTP wird nicht nur für Webseiten genutzt. Eigenständige Anwendungen können es als Grundlage für Webservices verwenden. Dabei dienen Methoden wie GET und POST zusammen mit PUT, PATCH und DELETE zur Umsetzung von CRUD-Operationen, also zum Erstellen, Lesen, Ändern und Löschen von Daten. REST verwendet diesen Ansatz beispielhaft. Ein Vorteil besteht darin, dass die Anwendung kein eigenes Protokoll für die Datenübertragung entwickeln muss.