RFC 9110 · Juni 2022 · Internet Standard

Was HTTP bedeutet, egal wie es reist.

Der offizielle Titel lautet "HTTP Semantics." Worüber der RFC wirklich entscheidet: die Bedeutung von HTTP selbst, seine Methoden, Status-Codes und Header-Felder, herausgelöst aus jeder einzelnen Version, sodass HTTP/1.1, HTTP/2 und HTTP/3 alle auf eine Definition zeigen können.

Status: ✓ Weiterhin gültig
Auch bekannt als: STD 97
Ersetzt: RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694
Aktualisiert: RFC 3864

Geschrieben von Noel Lang · IT-Trainer

Kurzfassung

RFC 9110 definiert die Semantik von HTTP: was Methoden (GET, POST, …), Status-Codes (200, 404, …) und Header-Felder bedeuten, unabhängig von jeder Version. Veröffentlicht im Juni 2022 als STD 97, hat er die verstreute 723x-Reihe (und den längst toten RFC 2616) in ein Dokument zusammengeführt. Er ist jetzt die eine Definition, auf die HTTP/1.1, HTTP/2 und HTTP/3 alle zurückzeigen. Wer heute “die HTTP-Spec” sagt, meint diesen RFC.

Welches Problem er löst

Fast das gesamte Leben von HTTP waren seine Bedeutung und sein Wire-Format in einem Dokument verschweißt. RFC 2616 von 1999 beschrieb HTTP/1.1 als eine Sache: was ein GET bedeutet und wie man es über eine TCP-Verbindung ausschreibt, in denselben Absätzen.

Das ging gut, bis HTTP aufhörte, eine Sache zu sein. HTTP/2 kam 2015 mit einem völlig anderen, binären Wire-Format, und HTTP/3 wechselte später ganz von TCP auf QUIC. Alle drei tragen dieselben Methoden, dieselben Status-Codes, dieselben Header. Aber es gab kein sauberes Dokument, das diese geteilte Bedeutung für sich definierte. Jede neue Version musste die Teile, die sich nie änderten, erneut referenzieren oder neu erklären.

RFC 9110 entwirrt das. Er zieht die versionsunabhängige Semantik an einen Ort und überlässt jeder Version nur noch, wie ihre Bytes auf die Leitung gehen: RFC 9112 für HTTP/1.1, RFC 9113 für HTTP/2, RFC 9114 für HTTP/3. Das Ergebnis: “was ein 404 bedeutet” steht genau einmal geschrieben, und jede Version leiht es sich aus.

Das große Neusortieren

Stell dir 25 Jahre HTTP-Wissen als ein Haus vor, an das immer neue Anbauten geschraubt wurden. RFC 2616 war ein großer Raum, in dem das Wörterbuch im selben Regal stand wie das Installationshandbuch. 2014 wurde der Raum in sechs geteilt (die 723x-Reihe), was half, aber Wörterbuch und Installation blieben quer über sie verteilt.

Die Neufassung von 2022 hat die Regale endlich sauber sortiert. Alles, was Bedeutung ist, die Wörter, die HTTP spricht, kam in RFC 9110. Alles, was Mechanik ist, wie eine bestimmte Version Bytes bewegt, kam in ihr eigenes Transport-Dokument. Das Caching, groß genug für sich allein, bekam sein eigenes Buch ( RFC 9111 ). Am Verhalten von HTTP änderte sich nichts. Das Wissen wurde nur dort abgelegt, wo man es findet.

Die praktische Konsequenz: Wenn du über eine Methode oder einen Status-Code liest, willst du RFC 9110, und nur 9110. Du musst 9112, 9113 oder 9114 fast nie öffnen, außer du schreibst einen Server oder eine Client-Bibliothek.

Die HTTP-Familie nach 2022

Ein Dokument definiert die Bedeutung; die Transport-Specs sitzen obendrauf und definieren die Bytes. Die alten Alles-in-einem-Specs bleiben nur für die Geschichte.

Semantik an der Basis, Transporte obendrauf. Diese vertikale Trennung ist die ganze Idee der Neufassung von 2022.

Semantik gegen Syntax, an einem Beispiel

Das Wort “Semantik” leistet hier viel Arbeit, deshalb hilft es, sie zu sehen. Semantik ist die Bedeutung: ein GET fordert eine Repräsentation einer Ressource an, sicher, ohne Seiteneffekte. Syntax ist, wie eine bestimmte Version diese Anfrage in tatsächliche Bytes schreibt.

In HTTP/1.1 ist eine Anfrage lesbarer Text: eine Anfragezeile, dann Header-Zeilen, jede endet mit Wagenrücklauf und Zeilenvorschub. In HTTP/3 ist dieselbe Anfrage ein komprimierter Satz von Feldern in einem binären QUIC-Frame, ohne Werkzeug nicht lesbar. Andere Bytes, Byte für Byte nichts gemeinsam. Dasselbe GET, dasselbe Ziel, dieselbe Bedeutung. RFC 9110 ist das Dokument, das sagt, was diese Bedeutung ist, damit beide Wire-Formate sich darauf einigen können, ohne sich zu wiederholen.

Ein GET, zwei Wire-Formate

Dieselbe Anfrage, ausgedrückt von zwei Versionen. Die Syntax ist über sie hinweg unkenntlich; die Semantik, einmal in RFC 9110 definiert, ist identisch.

Wenn du die linke Box lesen kannst, liest du Syntax. Was beide Boxen teilen, ist Semantik.

Die Methoden und die Versprechen, die sie geben

Zwei Eigenschaften entscheiden fast jeden Design-Streit. Sicher heißt nur lesend, keine beabsichtigte Änderung. Idempotent heißt, dass eine wiederholte Anfrage im selben Endzustand landet. Diese Tabelle ist die, nach der Interviewer immer wieder fragen:

Methode	Was sie garantiert
GET	Sicher und idempotent. Eine Repräsentation abholen, nichts verändern. Weil sie nichts verändert, darf die Antwort zwischengespeichert und vorgeladen werden. Nie Seiteneffekte hinter ein GET packen.
HEAD	Sicher und idempotent. Wie GET, aber es kommen nur die Header zurück, kein Body. Um Größe oder Aktualität günstig zu prüfen.
POST	Weder sicher noch idempotent. Daten zur Verarbeitung einreichen. Zweimal gesendet legt es womöglich zwei Bestellungen an. Die eine Methode ohne Wiederholungsgarantie.
PUT	Idempotent, nicht sicher. Die Ressource unter dieser URI durch das ersetzen, was du sendest. Ob einmal oder zehnmal, der Endzustand ist derselbe.
DELETE	Idempotent, nicht sicher. Die Ressource entfernen. Etwas bereits Gelöschtes zu löschen lässt es gelöscht, Wiederholen schadet also nicht.
OPTIONS	Sicher und idempotent. Fragen, was eine Ressource oder ein Server unterstützt. Das Rückgrat der CORS-Preflight-Prüfungen.
TRACE	Sicher und idempotent. Eine Loopback-Diagnose, die die Anfrage zurückspiegelt. Aus Sicherheitsgründen oft deaktiviert.
CONNECT	Weder sicher noch idempotent. Einen Tunnel durch einen Proxy aufbauen, der Mechanismus hinter HTTPS über einen HTTP-Proxy.

Status-Codes, nach erster Ziffer

Du merkst dir nicht 60-plus Codes, du lernst, was die erste Ziffer verspricht. RFC 9110 definiert fünf Klassen:

1xx Information

Moment, wird noch bearbeitet. Ein vorläufiges Signal, dass die Anfrage angekommen ist und weiterläuft. Im Alltag selten: 100 Continue, 101 Switching Protocols (der WebSocket-Upgrade), 103 Early Hints.
2xx Erfolg

Hat geklappt. Die Anfrage wurde empfangen, verstanden und akzeptiert. 200 OK, 201 Created nach einem erfolgreichen POST, 204 No Content, wenn es nichts zurückzusenden gibt.
3xx Umleitung

Schau woanders. Es braucht einen weiteren Schritt, meist das Folgen einer neuen Adresse. 301 Moved Permanently, 304 Not Modified (deine zwischengespeicherte Kopie ist noch frisch), 308 Permanent Redirect.
4xx Client-Fehler

Du hast Mist gebaut. Die Anfrage war fehlerhaft oder nicht erlaubt. 400 Bad Request, 401 Unauthorized, 403 Forbidden und der berühmte 404 Not Found.
5xx Server-Fehler

Wir haben Mist gebaut. Die Anfrage sah gut aus, aber der Server ist beim Bearbeiten gescheitert. 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

Welcher RFC ist HTTP eigentlich?

Das ist die Frage, die der Spec-Text nie sauber beantwortet, und der Grund, warum Leute tote Dokumente zitieren. HTTP ist nicht ein RFC. Seit Juni 2022 ist es eine kleine Familie, und welcher davon du willst, hängt davon ab, was du meinst.

Kurzfassung: für die Bedeutung willst du RFC 9110, immer. Für das Wire-Format einer bestimmten Version willst du 9112, 9113 oder 9114. Und greif auf keinen Fall zu RFC 2616: er verlor seine Autorität 2014 und wurde 2022 erneut ersetzt, ist aber immer noch das oberste Suchergebnis, und genau so verbreiten sich veraltete Ratschläge.

Welches Dokument du zitieren solltest

Eine Nachschlagetabelle für die ewige Verwechslung:

Wenn du meinst	Das Dokument, und ob es aktuell ist
"HTTP", die Bedeutung	RFC 9110 (2022). Methoden, Status-Codes, Header. Aktuell, STD 97. Das ist es, was man heute meinen sollte.
HTTP/1.1, das Wire-Format	RFC 9112 (2022). Die Textzeilen-Syntax. Aktuell, STD 99. Er hat RFC 7230 abgelöst.
HTTP/2	RFC 9113 (2022). Binäres Framing und Multiplexing über eine TCP-Verbindung. Aktuell, hat RFC 7540 abgelöst.
HTTP/3	RFC 9114 (2022). Dieselbe Semantik, transportiert über QUIC statt TCP. Aktuell.
HTTP-Caching	RFC 9111 (2022). Aus der Semantik in ein eigenes Dokument herausgelöst, STD 98. Hat RFC 7234 abgelöst.
"Der HTTP/1.1-RFC" (2616)	Seit 2014 veraltet, 2022 erneut ersetzt. Nur noch historisch. Nicht für aktuelles Verhalten zitieren.

Was RFC 9110 wirklich sagt

Das Dokument ist lang (rund 200 Seiten), weil es mehrere ältere aufgesogen hat. Die Landkarte, falls du vorbeischaust:

Abschnitt	In einfachen Worten
2–3 · Architektur & Begriffe	Clients, Server, Intermediäre, Ressourcen, Repräsentationen. Das gemeinsame Vokabular, das jede Version erbt.
4 · URIs (http und https)	Was die Schemata http und https bedeuten, aufgebaut auf der URI-Syntax von RFC 3986. Hier ist HTTPS verankert.
5–8 · Felder, Inhalt, Verhandlung	Wie Header-Felder funktionieren, was ein Message-Body ist und wie Client und Server sich auf Format und Sprache einigen.
9 · Methoden	Die acht Methoden und ihre Eigenschaften: welche sicher, welche idempotent, welche cachebar sind.
10–14 · Ausgewählte Header-Felder	Referer, Allow, bedingte Anfragen, Range-Anfragen, Authentifizierung. Die Teile, die die 723x-Reihe getrennt behandelte.
15 · Status-Codes	Die fünf Klassen und jeder registrierte Code, inklusive 418, reserviert aber ungenutzt, damit ihn niemand versehentlich vergibt.

Was Leute falsch verstehen

"RFC 2616 ist die HTTP-Spec."

War er, bis 2014. RFC 2616 (1999) ist seit über einem Jahrzehnt veraltet: zuerst ersetzt durch die sechsteilige 723x-Reihe, dann 2022 erneut neu sortiert in RFC 9110 und die Transport-Specs. Wer 2616 heute zitiert, verweist Leute auf ein Dokument, das seit Jahren im Detail falsch liegt. Die aktuelle Antwort ist RFC 9110.
"HTTP/2 und HTTP/3 haben neue Methoden gebracht."

Haben sie nicht. Methoden und Status-Codes stehen in RFC 9110 und werden von jeder Version geteilt. Was HTTP/2 und HTTP/3 geändert haben, ist rein das Wire-Format: binäre Frames, Multiplexing, Header-Kompression und bei HTTP/3 der Wechsel von TCP zu QUIC. Ein GET bedeutet in allen dreien exakt dasselbe.
"RFC 9110 definiert HTTPS."

Nur die äußere Hülle. RFC 9110 definiert das https-URI-Schema und hat den alten RFC 2818 aufgesogen, hier ist HTTPS also verankert. Die Verschlüsselung selbst definiert er aber nicht. Das ist TLS, ein völlig eigenständiges Protokoll (RFC 8446 für TLS 1.3). HTTPS ist einfach HTTP-Semantik, getragen über eine TLS-Verbindung.
"PUT gegen POST ist Geschmackssache."

Nein, RFC 9110 gibt ihnen unterschiedliche, prüfbare Eigenschaften. PUT ist idempotent: zweimal gesendet bleibt der Endzustand gleich. POST ist es nicht: zweimal gesendet legt es womöglich zwei Datensätze an. PUT ersetzt eine Ressource unter einer URI, die du schon kennst; POST übergibt Daten an einen Endpunkt, der sie verarbeitet, wie er will. Die Wahl ist definiertes Verhalten, kein Stil.

Wo dir RFC 9110 begegnet

Du liest ihn selten, aber du verlässt dich ständig auf ihn. Ein Feldführer:

Du siehst	Du verlässt dich auf 9110 für
MDN-Seiten zu Methoden und Status	Jede MDN-Referenz zu einer Methode oder einem Status-Code verlinkt als normative Quelle zurück auf ihre Definition in RFC 9110.
Ein Streit über REST-API-Design	Wenn jemand darauf besteht, PUT müsse idempotent sein oder POST dürfe nicht gecacht werden, zitiert er 9110, ob er ihn nennt oder nicht.
curl -X und -I	Die Methoden, die curl sendet, und die Header, die es ausgibt, sind genau die, die 9110 definiert. HEAD hinter -I, Methoden hinter -X.
Ein Problem-Details-JSON-Body	RFC 9457 kombiniert einen 9110-Status-Code mit einer strukturierten Erklärung. Die Status-Code-Hälfte ist reines 9110-Vokabular.
Ein 100 Continue beim Upload	Dieser vorläufige 1xx-Handshake vor einem großen PUT- oder POST-Body ist in 9110, Abschnitt 15, definiert.

Fragen, die wirklich gestellt werden

Was ist der Unterschied zwischen RFC 9110 und RFC 9112? +

RFC 9110 definiert, was HTTP bedeutet: Methoden, Status-Codes und Header, in jeder Version gleich. RFC 9112 definiert nur, wie HTTP/1.1 diese Bedeutung auf die Leitung bringt, nämlich als Textzeilen, die mit CRLF enden, samt Chunked Transfer Encoding. 9110 ist das Vokabular, 9112 eine Art, es zu sprechen. HTTP/2 und HTTP/3 nutzen dasselbe 9110-Vokabular mit ihren eigenen Wire-Formaten (9113 und 9114).

Was ist der Unterschied zwischen RFC 9110 und RFC 2616? +

RFC 2616 (1999) war die einzelne Alles-in-einem-Spezifikation für HTTP/1.1 und ist seit 2014 veraltet. Sein Inhalt wurde zuerst in die 723x-Reihe aufgeteilt, dann 2022 erneut neu sortiert, sodass Bedeutung (RFC 9110) vom Wire-Format (RFC 9112) getrennt ist. Für alles Aktuelle zitierst du 9110, nie 2616.

Ist RFC 2616 noch gültig? +

Nein. RFC 2616 wurde im Juni 2014 für veraltet erklärt und im Juni 2022 erneut ersetzt. Er wird nur noch zu historischen Zwecken online gehalten. Die lebende Definition von HTTP verteilt sich heute auf RFC 9110 (Semantik) und die versionsspezifischen Specs 9112, 9113 und 9114.

Ersetzt RFC 9110 den RFC 7231? +

Ja. RFC 9110 löst die Semantik-Hälfte der 723x-Reihe ab (7230, 7231, 7232, 7233, 7235) samt mehrerer kleinerer HTTP-RFCs und fasst sie in ein Dokument. Er ist jetzt STD 97. Das Caching, früher RFC 7234, ist separat in RFC 9111 umgezogen.

Was bedeutet "HTTP-Semantik" eigentlich? +

Die Teile von HTTP, die unabhängig von der Version gleich bleiben: was GET, POST und DELETE bedeuten, was ein 404 oder 301 signalisiert, wie Header-Felder wie Content-Type funktionieren. RFC 9110 definiert das, während getrennte RFCs festlegen, wie die Bytes für jede Version auf die Leitung geschrieben werden.

Haben HTTP/2 und HTTP/3 neue Methoden oder Status-Codes hinzugefügt? +

Nein. Methoden und Status-Codes werden einmal definiert, in RFC 9110, und von jeder Version geteilt. HTTP/2 und HTTP/3 haben nur das Wire-Format geändert (binäres Framing, Multiplexing, Header-Kompression). Ein GET ist weiterhin ein GET und ein 404 weiterhin ein 404, ob es als HTTP/1.1-Text oder als HTTP/3-QUIC-Frame ankommt.

Was war HTTP/0.9? +

Die ursprüngliche Version von HTTP aus dem Jahr 1991: eine einzige Anfragezeile wie GET /seite, ohne Header, ohne Status-Codes und ohne Versionsnummer. Sie wurde nie als eigener RFC veröffentlicht. Alles, was danach kam, bis hin zu RFC 9110, ist die Geschichte, wie die Bedeutung nachgereicht wurde, die 0.9 fehlte.

Definiert RFC 9110 HTTPS? +

Teilweise. RFC 9110 definiert das https-URI-Schema und hat den alten RFC 2818 ("HTTP over TLS") aufgesogen, hier ist HTTPS also verankert. Die Verschlüsselung selbst definiert er aber nicht: das ist TLS, ein eigenständiges Protokoll (RFC 8446 für TLS 1.3). HTTPS ist schlicht HTTP-Semantik, transportiert über eine TLS-Verbindung.

Verweise hierher

Andere Erklärseiten auf dieser Website, die auf diesen RFC zurückverweisen:

Wie RFC 9110 zusammenhängt

Was vorher kam

RFC 2616 (1999) war 15 Jahre lang das HTTP/1.1-Dokument. Seit 2014 veraltet, 2022 erneut ersetzt. Wer "der HTTP-RFC" sagt und 2616 meint, zitiert ein seit einem Jahrzehnt totes Dokument.