1. Introduction (Einführung)

1.1. Purpose (Zweck)

Das Hypertext Transfer Protocol (HTTP) ist eine Familie von zustandslosen (Stateless), anwendungsebenen (Application-Level) Anfrage/Antwort-Protokollen (Request/Response Protocols), die eine generische Schnittstelle (Generic Interface), erweiterbare Semantik (Extensible Semantics) und selbstbeschreibende Nachrichten (Self-Descriptive Messages) teilen, um flexible Interaktionen mit netzwerkbasierten Hypertext-Informationssystemen zu ermöglichen.

HTTP verbirgt die Details der Implementierung eines Dienstes, indem es den Clients eine einheitliche Schnittstelle (Uniform Interface) präsentiert, die unabhängig von den Arten der bereitgestellten Ressourcen ist. Ebenso müssen Server nicht über den Zweck jedes Clients informiert sein: Eine Anfrage kann isoliert betrachtet werden, anstatt mit einem bestimmten Client-Typ oder einer vorbestimmten Sequenz von Anwendungsschritten verknüpft zu sein. Dies ermöglicht die effektive Verwendung von Allzweck-Implementierungen in vielen verschiedenen Kontexten, reduziert die Interaktionskomplexität und ermöglicht eine unabhängige Entwicklung im Laufe der Zeit.

HTTP ist auch als Vermittlungsprotokoll (Intermediation Protocol) konzipiert, bei dem Proxies (Proxies) und Gateways (Gateways) Nicht-HTTP-Informationssysteme in eine allgemeinere Schnittstelle übersetzen können.

Eine Konsequenz dieser Flexibilität ist, dass das Protokoll nicht in Bezug auf das definiert werden kann, was hinter der Schnittstelle geschieht. Stattdessen sind wir darauf beschränkt, die Syntax der Kommunikation (Syntax of Communication), die Absicht der empfangenen Kommunikation (Intent) und das erwartete Verhalten der Empfänger (Expected Behavior) zu definieren. Wenn die Kommunikation isoliert betrachtet wird, sollten erfolgreiche Aktionen sich in entsprechenden Änderungen an der von Servern bereitgestellten beobachtbaren Schnittstelle widerspiegeln. Da jedoch mehrere Clients parallel und möglicherweise mit gegensätzlichen Zielen handeln können, können wir nicht verlangen, dass solche Änderungen über den Bereich einer einzelnen Antwort hinaus beobachtbar sind.

1.2. History and Evolution (Geschichte und Entwicklung)

HTTP ist seit seiner Einführung im Jahr 1990 das primäre Informationsübertragungsprotokoll für das World Wide Web. Es begann als trivialer Mechanismus für Anfragen mit niedriger Latenz, mit einer einzigen Methode (GET), um die Übertragung eines vermuteten Hypertext-Dokuments anzufordern, das durch einen gegebenen Pfadnamen identifiziert wurde. Als das Web wuchs, wurde HTTP erweitert, um Anfragen und Antworten in Nachrichten einzuschließen, beliebige Datenformate unter Verwendung von MIME-ähnlichen Medientypen (Media Types) zu übertragen und Anfragen über Vermittler (Intermediaries) zu routen. Diese Protokolle wurden schließlich als HTTP/0.9 und HTTP/1.0 definiert (siehe [HTTP/1.0]).

HTTP/1.1 wurde entwickelt, um die Funktionen des Protokolls zu verfeinern und gleichzeitig die Kompatibilität mit der bestehenden textbasierten Messaging-Syntax beizubehalten, wodurch seine Interoperabilität (Interoperability), Skalierbarkeit (Scalability) und Robustheit (Robustness) im Internet verbessert wurden. Dies umfasste längenbasierte Datenbegrenzer (Length-Based Data Delimiters) für feste und dynamische (chunked, Chunked) Inhalte, ein konsistentes Framework für Content-Negotiation (Content Negotiation), opake Validatoren (Opaque Validators) für bedingte Anfragen (Conditional Requests), Cache-Steuerungen (Cache Controls) für bessere Cache-Konsistenz, Bereichsanfragen (Range Requests) für teilweise Updates und standardmäßig persistente Verbindungen (Persistent Connections). HTTP/1.1 wurde 1995 eingeführt und 1997 auf dem Standards Track veröffentlicht [RFC2068], 1999 überarbeitet [RFC2616] und 2014 erneut überarbeitet ([RFC7230] bis [RFC7235]).

HTTP/2 ([HTTP/2]) führte eine multiplexe Sitzungsschicht (Multiplexed Session Layer) über den bestehenden TLS- und TCP-Protokollen ein, um gleichzeitige HTTP-Nachrichten mit effizienter Feldkompression (Field Compression) und Server-Push (Server Push) auszutauschen. HTTP/3 ([HTTP/3]) bietet größere Unabhängigkeit für gleichzeitige Nachrichten, indem es QUIC als sicheren multiplexen Transport über UDP anstelle von TCP verwendet.

Alle drei Hauptversionen von HTTP basieren auf der in diesem Dokument definierten Semantik. Sie haben sich nicht gegenseitig obsolet gemacht, da jede spezifische Vorteile und Einschränkungen je nach Verwendungskontext hat. Implementierungen sollten den am besten geeigneten Transport und die Messaging-Syntax für ihren spezifischen Kontext wählen.

Diese Überarbeitung von HTTP trennt die Definition der Semantik (dieses Dokument) und des Cachings ([CACHING]) von der aktuellen HTTP/1.1-Messaging-Syntax ([HTTP/1.1]), um jeder Hauptprotokollversion zu ermöglichen, unabhängig fortzuschreiten, während sie sich auf dieselbe Kernsemantik bezieht.

1.3. Core Semantics (Kernsemantik)

HTTP bietet eine einheitliche Schnittstelle für die Interaktion mit einer Ressource (Resource, Abschnitt 3.1) - unabhängig von ihrem Typ, ihrer Natur oder ihrer Implementierung - durch das Senden von Nachrichten, die Repräsentationen (Representations, Abschnitt 3.2) manipulieren oder übertragen.

Jede Nachricht ist entweder eine Anfrage (Request) oder eine Antwort (Response). Ein Client konstruiert Anfragenachrichten, die seine Absichten kommunizieren, und leitet diese Nachrichten zu einem identifizierten Ursprungsserver (Origin Server). Ein Server lauscht auf Anfragen, analysiert jede empfangene Nachricht, interpretiert die Nachrichtensemantik in Bezug auf die identifizierte Zielressource (Target Resource) und antwortet auf diese Anfrage mit einer oder mehreren Antwortnachrichten. Der Client untersucht empfangene Antworten, um zu sehen, ob seine Absichten ausgeführt wurden, und bestimmt basierend auf den empfangenen Statuscodes (Status Codes) und Inhalten, was als Nächstes zu tun ist.

Die HTTP-Semantik umfasst die durch jede Anfragemethode (Abschnitt 9) definierten Absichten, Erweiterungen dieser Semantik, die möglicherweise in Anfrage-Header-Feldern (Request Header Fields) beschrieben werden, Statuscodes, die die Antwort beschreiben (Abschnitt 15), und andere Kontrolldaten und Ressourcen-Metadaten (Resource Metadata), die möglicherweise in Antwortfeldern angegeben werden.

Die Semantik umfasst auch Repräsentations-Metadaten (Representation Metadata), die beschreiben, wie Inhalte von einem Empfänger interpretiert werden sollen, Anfrage-Header-Felder, die die Inhaltsauswahl beeinflussen können, und die verschiedenen Auswahlalgorithmen, die zusammen als „Content-Negotiation" (Content Negotiation, Abschnitt 12) bezeichnet werden.

1.4. Specifications Obsoleted by This Document (Durch dieses Dokument obsolete Spezifikationen)

Titel	Referenz	Siehe
HTTP Over TLS	[RFC2818]	B.1
HTTP/1.1 Message Syntax and Routing [*]	[RFC7230]	B.2
HTTP/1.1 Semantics and Content	[RFC7231]	B.3
HTTP/1.1 Conditional Requests	[RFC7232]	B.4
HTTP/1.1 Range Requests	[RFC7233]	B.5
HTTP/1.1 Authentication	[RFC7235]	B.6
HTTP Status Code 308 (Permanent Redirect)	[RFC7538]	B.7
HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields	[RFC7615]	B.8
HTTP Client-Initiated Content-Encoding	[RFC7694]	B.9

Tabelle 1

[*] Dieses Dokument macht nur die Teile von RFC 7230 obsolet, die unabhängig von der HTTP/1.1-Messaging-Syntax und dem Verbindungsmanagement sind; der Rest von RFC 7230 wird durch „HTTP/1.1" [HTTP/1.1] obsolet gemacht.

---