1. Einführung

Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Anfrage/Antwort-Protokoll auf Anwendungsebene, das erweiterbare Semantik und selbstbeschreibende Nachrichten-Payloads für eine flexible Interaktion mit netzbasierten Hypertext-Informationssystemen verwendet. Dieses Dokument ist das erste in einer Reihe von Dokumenten, die gemeinsam die HTTP/1.1-Spezifikation bilden:

1. "Message Syntax and Routing" (dieses Dokument)

2. "Semantics and Content" [RFC7231]

3. "Conditional Requests" [RFC7232]

4. "Range Requests" [RFC7233]

5. "Caching" [RFC7234]

6. "Authentication" [RFC7235]

Diese HTTP/1.1-Spezifikation ersetzt RFC 2616 und RFC 2145 (zur HTTP-Versionierung). Diese Spezifikation aktualisiert außerdem die Verwendung von CONNECT zum Aufbau eines Tunnels, die zuvor in RFC 2817 definiert wurde, und definiert das "https"-URI-Schema, das in RFC 2818 informell beschrieben wurde.

HTTP ist ein generisches Schnittstellenprotokoll für Informationssysteme. Es ist darauf ausgelegt, die Details der Implementierung eines Dienstes zu verbergen, indem es Clients eine einheitliche Schnittstelle präsentiert, die unabhängig von den bereitgestellten Ressourcentypen ist. Ebenso müssen Server den Zweck jedes einzelnen Clients nicht kennen: Eine HTTP-Anfrage kann isoliert betrachtet werden, statt mit einem bestimmten Client-Typ oder einer vorgegebenen Abfolge von Anwendungsschritten verknüpft zu werden. Das Ergebnis ist ein Protokoll, das in vielen verschiedenen Kontexten effektiv eingesetzt werden kann und dessen Implementierungen sich im Laufe der Zeit unabhängig weiterentwickeln können.

HTTP ist außerdem für die Verwendung als Vermittlungsprotokoll (intermediation protocol) konzipiert, um Kommunikation zu und von Nicht-HTTP-Informationssystemen zu übersetzen. HTTP-Proxys und -Gateways können Zugang zu alternativen Informationsdiensten bieten, indem sie deren unterschiedliche Protokolle in ein Hypertext-Format übersetzen, das von Clients genauso betrachtet und manipuliert werden kann wie HTTP-Dienste.

Eine Folge dieser Flexibilität ist, dass das Protokoll nicht anhand dessen definiert werden kann, was hinter der Schnittstelle geschieht. Stattdessen sind wir darauf beschränkt, die Syntax der Kommunikation, die Absicht der empfangenen Kommunikation und das erwartete Verhalten der Empfänger zu definieren. Wird die Kommunikation isoliert betrachtet, so sollten sich erfolgreiche Aktionen in entsprechenden Änderungen der von den Servern bereitgestellten beobachtbaren Schnittstelle widerspiegeln. Da jedoch mehrere Clients parallel und möglicherweise mit gegensätzlichen Zielen agieren können, können wir nicht verlangen, dass solche Änderungen über den Umfang einer einzelnen Antwort hinaus beobachtbar sind.

Dieses Dokument beschreibt die Architekturelemente, die in HTTP verwendet oder erwähnt werden, definiert die URI-Schemata "http" und "https", beschreibt den allgemeinen Netzbetrieb und die Verbindungsverwaltung und legt die Anforderungen an HTTP-Nachrichten-Framing und -Weiterleitung fest. Unser Ziel ist es, alle Mechanismen zu definieren, die für die Verarbeitung von HTTP-Nachrichten erforderlich und von der Nachrichtensemantik unabhängig sind, und damit die vollständige Menge von Anforderungen für Nachrichten-Parser und nachrichtenweiterleitende Vermittler festzulegen.

1.1. Anforderungsnotation

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind gemäß [RFC2119] zu interpretieren.

Konformitätskriterien und Überlegungen zur Fehlerbehandlung sind in Abschnitt 2.5 definiert.

1.2. Syntaxnotation

Diese Spezifikation verwendet die Notation der Augmented Backus-Naur Form (ABNF) aus [RFC5234] mit einer Listenerweiterung, die in Abschnitt 7 definiert ist und die kompakte Definition von durch Kommas getrennten Listen mit einem #-Operator ermöglicht (ähnlich wie der *-Operator Wiederholung anzeigt). Anhang B zeigt die gesammelte Grammatik, wobei alle Listenoperatoren in die Standard-ABNF-Notation expandiert wurden.

Die folgenden Kernregeln sind per Verweis enthalten, wie in [RFC5234], Anhang B.1, definiert: ALPHA (Buchstaben), CR (Wagenrücklauf), CRLF (CR LF), CTL (Steuerzeichen), DIGIT (Dezimalziffer 0-9), DQUOTE (doppeltes Anführungszeichen), HEXDIG (Hexadezimalziffer 0-9/A-F/a-f), HTAB (horizontaler Tabulator), LF (Zeilenvorschub), OCTET (beliebige 8-Bit-Datensequenz), SP (Leerzeichen) und VCHAR (beliebiges sichtbares [USASCII]-Zeichen).

Als Konvention bezeichnen ABNF-Regelnamen mit dem Präfix "obs-" "veraltete" Grammatikregeln, die aus historischen Gründen erscheinen.