Auch genannt: HTTP
Das Hypertext Transfer Protocol (HTTP) ist ein Protokoll der Anwendungsschicht, mit dem Clients und Server im Web Informationen austauschen. Ein Browser, eine App oder ein anderes Programm sendet eine Anfrage an eine bestimmte Ressource; ein Server antwortet darauf mit einem Status, Kopfzeilen und bei Bedarf mit Inhalt. HTTP legt vor allem die Bedeutung dieser Kommunikation fest, nicht die Gestaltung einer Website. Der Standard beschreibt HTTP als zustandsloses Request/Response-Protokoll für verteilte Hypertext-Informationssysteme.RFC 9112: HTTP/1.1
Wenn jemand eine Webseite aufruft, muss der Browser dem Server mitteilen, welche Ressource er benötigt. Er sendet beispielsweise eine Anfrage für eine Seite oder eine Bilddatei. Der Server antwortet etwa mit dem Status 200 OK und dem angeforderten HTML-Dokument. Erkennt der Server die Ressource nicht, kann er 404 Not Found zurückgeben. Diese Statuscodes sind keine frei erfundenen Browsermeldungen, sondern Teil der HTTP-Semantik.RFC 9110: HTTP Semantics, Abschnitt 15
Die Adresse, auf die sich eine Anfrage bezieht, ist dabei nicht mit dem Protokoll selbst gleichzusetzen. Eine URI dient allgemein dazu, eine Ressource zu identifizieren; URL und URN sind dafür Spezialisierungen.RFC 3986: URI Generic Syntax HTTP definiert, wie ein Client eine Anfrage an ein Ziel richtet und wie eine Antwort zu verstehen ist. Eine Domain hilft beim Auffinden eines Ziels im Netz, ist aber weder HTTP noch die angeforderte Ressource selbst.
Eine HTTP-Anfrage hat eine Methode, ein Ziel und weitere Angaben. Bei HTTP/1.1 beginnt sie mit einer Request-Line, in der Methode, Request-Target und Protokollversion stehen. Danach folgen Header-Felder; gegebenenfalls kommt ein Nachrichteninhalt hinzu.RFC 9112: HTTP/1.1, Abschnitt 3 Header transportieren Kontext, zum Beispiel welche Formate der Client akzeptiert oder welchen Inhaltstyp der Server liefert. Der Body enthält häufig die eigentlichen Nutzdaten: HTML für eine Seite, JSON für eine Programmierschnittstelle oder Daten aus einem Formular.
Die Antwort folgt demselben Grundgedanken. Sie enthält einen Statuscode, Header und oft Inhalt. Bei einer erfolgreichen GET-Anfrage mit 200 OK repräsentiert der Inhalt den aktuellen Zustand der Zielressource zum Zeitpunkt der Antwort. Eine HEAD-Antwort enthält dagegen keinen Inhalt; ihre Header zeigen nur, welche Werte eine entsprechende GET-Antwort hätte.RFC 9110: HTTP Semantics, Abschnitt 6.4 Diese Unterscheidung ist praktisch, wenn ein Programm erst Eigenschaften einer Ressource prüfen will, ohne die vollständige Datei abzurufen.
HTTP kennt keine auf Webbrowser beschränkten Datenformate. Deshalb kann derselbe Grundmechanismus eine klassische Webseite, eine mobile App und eine Schnittstelle zwischen Servern bedienen. Die Semantik bleibt auf der Ebene von Anfrage, Ziel, Methode, Status und Repräsentation vergleichbar, auch wenn HTTP/1.1, HTTP/2 oder neuere Versionen Nachrichten technisch unterschiedlich übertragen.
Die Methode beschreibt, welche Operation der Client anfragt. GET dient typischerweise dazu, eine Darstellung einer Ressource abzurufen. POST übermittelt Daten zur Verarbeitung; ein erfolgreich verarbeitetes Formular kann deshalb eine andere Antwortbedeutung haben als ein Seitenabruf. PUT kann eine gewünschte neue Repräsentation des Ziels enthalten. Welche Wirkung am Ende eintritt, hängt dennoch von der Anwendung und ihren Zugriffsregeln ab. HTTP ersetzt keine fachliche Prüfung, etwa ob eine Person ein Konto ändern darf.RFC 9110: HTTP Semantics, Abschnitt 9
Statuscodes geben das Ergebnis in Klassen wieder. 2xx steht für Erfolg, 3xx für Umleitungen, 4xx weist im Regelfall auf ein Problem der Anfrage hin und 5xx auf einen Fehler auf Serverseite. Ein 404 Not Found bedeutet nicht zwingend, dass eine Datei für immer verschwunden ist; die Spezifikation sagt, dass der Origin-Server keine aktuelle Repräsentation für das Ziel gefunden hat oder ihre Existenz nicht offenlegen will.RFC 9110: HTTP Semantics, Abschnitt 15.5.5 Für Nutzerinnen und Nutzer ist der Code eine knappe Rückmeldung, für Programme eine Grundlage, um etwa eine Umleitung zu verfolgen oder einen Fehler zu behandeln.
HTTP gilt als zustandslos: Jede Anfrage ist für sich verständlich, ohne dass das Protokoll selbst eine dauerhafte Sitzung zwischen Client und Server führen muss. Das heißt nicht, dass Websites keine angemeldeten Bereiche haben können. Eine Shop- oder Banking-Anwendung kann zusätzliche Mechanismen nutzen, etwa Cookies, Sitzungskennungen oder Zugriffstoken. Der Server ordnet damit Anfragen einem Konto oder Warenkorb zu; der Zustand gehört zur Anwendung, nicht zur Grundbedeutung von HTTP.
Ein Beispiel: Nach dem Einloggen in einen Online-Shop ruft ein Browser die Bestellübersicht ab. Er sendet eine GET-Anfrage mit den nötigen Kontextdaten, etwa einem Cookie. Die Anwendung prüft diese Daten und antwortet bei Erfolg mit der Übersicht. Wird die Sitzung nicht akzeptiert, kann sie statt der Bestellliste eine Anmeldung verlangen. HTTP liefert den Rahmen für diesen Austausch, entscheidet aber nicht selbst, ob die Person berechtigt ist oder welche Produkte im Warenkorb liegen.
Die Zustandslosigkeit erleichtert es, einzelne Anfragen über mehrere Server zu verteilen. Zugleich müssen Betreiber sorgfältig festlegen, wie Sitzungen, Caches und Berechtigungen behandelt werden. Ein Cache darf beispielsweise nicht versehentlich eine persönliche Antwort an die falsche Person ausliefern. Solche Fragen bauen auf HTTP auf, gehen aber über die bloße Übertragung einer Anfrage hinaus.
HTTP ist nicht automatisch verschlüsselt. Das URI-Schema http bezeichnet HTTP ohne den Schutz von TLS; bei https wird HTTP über eine gesicherte TLS-Verbindung verwendet. TLS ist dafür ausgelegt, Client-Server-Kommunikation gegen Abhören, Manipulation und Nachrichtenfälschung zu schützen.RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 HTTPS ist somit nicht ein anderes Austauschmodell für Webseiten, sondern HTTP mit einem zusätzlichen Schutz der Verbindung.
TCP ist ebenfalls etwas anderes: Es ist ein Transportprotokoll. HTTP/1.1 wird üblicherweise über eine zuverlässige, geordnete Transportverbindung übertragen; HTTP selbst ist von der konkreten Transport- oder Sitzungsschicht-Verbindung unabhängig.RFC 9112: HTTP/1.1, Abschnitt 9 Vereinfacht gesagt: HTTP beschreibt, was Anfrage und Antwort bedeuten; TLS schützt die Verbindung; TCP transportiert bei verbreiteten HTTP-Versionen die Daten zwischen den Endpunkten. Diese Schichten lösen verschiedene Aufgaben und sollten nicht als Synonyme verwendet werden.
HTTPS ist HTTP über TLS und schützt den Übertragungsweg, sofern die Verbindung korrekt aufgebaut und geprüft wurde. TCP transportiert Daten zuverlässig und geordnet, legt aber nicht fest, was ein Seitenabruf oder ein Statuscode bedeutet. Eine URI beziehungsweise URL benennt oder lokalisiert eine Ressource; HTTP regelt den Austausch über diese Ressource. Auch eine API ist kein Ersatzbegriff für HTTP: Eine API kann HTTP als Kommunikationsprotokoll nutzen, definiert aber zusätzlich eigene Endpunkte, Datenformate und Geschäftsregeln.
Stand der Quellen: 13. September 2026