Zum Hauptinhalt springen

RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Nachrichtensyntax und Routing

  • Status: Proposed Standard
  • Veröffentlicht: June 2014
  • Stream: IETF
  • Aktualisiert: RFC2817, RFC2818
  • Ersetzt: RFC2145, RFC2616
  • Ersetzt durch: RFC9110, RFC9112
  • Errata: Keine Errata

Dokumentinformationen​

  • RFC-Nummer: 7230
  • Titel: HTTP/1.1: Message Syntax and Routing (Nachrichtensyntax und Routing)
  • Veröffentlicht: Juni 2014
  • Autoren: R. Fielding (Adobe), J. Reschke (greenbytes)
  • Status: Standards Track
  • Ersetzt: RFC 2616, RFC 2145
  • Aktualisiert: RFC 2817, RFC 2818

Zusammenfassung (Abstract)​

Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Anwendungsschichtprotokoll für verteilte, kollaborative Hypertext-Informationssysteme. Dieses Dokument gibt einen Überblick über die HTTP-Architektur und die zugehörige Terminologie, definiert die URI-Schemata (Uniform Resource Identifier) „http" und „https", legt die HTTP/1.1-Nachrichtensyntax und Parsing-Anforderungen fest und beschreibt damit verbundene Sicherheitsüberlegungen für Implementierungen.

Dokumentstruktur (Inhaltsverzeichnis)​

Hauptabschnitte​

  1. Introduction (Einführung)

    • 1.1 Requirements Notation (Anforderungsnotation)
    • 1.2 Syntax Notation (Syntaxnotation)

  2. Architecture (Architektur)

    • 2.1 Client/Server Messaging (Client/Server-Nachrichtenübermittlung)
    • 2.2 Implementation Diversity (Implementierungsvielfalt)
    • 2.3 Intermediaries (Vermittler)
    • 2.4 Caches (Zwischenspeicher)
    • 2.5 Conformance and Error Handling (Konformität und Fehlerbehandlung)
    • 2.6 Protocol Versioning (Protokollversionierung)
    • 2.7 Uniform Resource Identifiers (Einheitliche Ressourcenbezeichner)

  3. Message Format (Nachrichtenformat)

    • 3.1 Start Line (Startzeile)
    • 3.2 Header Fields (Header-Felder)
    • 3.3 Message Body (Nachrichtenrumpf)

  4. Transfer Codings (Übertragungscodierungen)

    • 4.1 Chunked Transfer Coding (Chunked-Übertragungscodierung)
    • 4.2 Compression Codings (Kompressionscodierungen)
    • 4.3 TE Header Field
    • 4.4 Trailer Header Field

  5. Message Routing (Nachrichtenrouting)

    • 5.1 Identifying a Target Resource (Identifizierung einer Zielressource)
    • 5.2 Connecting Inbound (Eingehende Verbindung)
    • 5.3 Request Target (Anforderungsziel)
    • 5.4 Host Header Field
    • 5.5 Effective Request URI
    • 5.6 Associating a Response to a Request (Zuordnung einer Antwort zu einer Anforderung)
    • 5.7 Message Forwarding (Nachrichtenweiterleitung)

  6. Connection Management (Verbindungsverwaltung)

    • 6.1 Connection Header Field
    • 6.2 Establishment (Verbindungsaufbau)
    • 6.3 Persistence (Persistente Verbindungen)
    • 6.4 Concurrency (Parallelität)
    • 6.5 Failures and Timeouts (Fehler und Zeitüberschreitungen)
    • 6.6 Tear-down (Verbindungsabbau)
    • 6.7 Upgrade Header Field

  7. ABNF List Extension (ABNF-Listenerweiterung)

  8. IANA Considerations (IANA-Überlegungen)

  9. Security Considerations (Sicherheitsüberlegungen)

Anhänge​

HTTP/1.1-Spezifikationsreihe​

RFC 7230 ist der erste Teil der HTTP/1.1-Spezifikationsreihe. Die vollständige Reihe umfasst:

  1. RFC 7230 - Message Syntax and Routing (dieses Dokument)
  2. RFC 7231 - Semantics and Content (Semantik und Inhalt)
  3. RFC 7232 - Conditional Requests (Bedingte Anforderungen)
  4. RFC 7233 - Range Requests (Bereichsanforderungen)
  5. RFC 7234 - Caching (Zwischenspeicherung)
  6. RFC 7235 - Authentication (Authentifizierung)

Schlüsselkonzepte​

Kernbegriffe​

  • Client (Client): Ein Programm, das eine Verbindung herstellt, um HTTP-Anforderungen zu senden
  • Server (Server): Ein Programm, das Verbindungen akzeptiert, um HTTP-Anforderungen zu bedienen
  • User Agent (Benutzeragent): Ein Client-Programm, das Anforderungen initiiert (Browser, Crawler usw.)
  • Origin Server (Ursprungsserver): Ein Programm, das maßgebliche Antworten für eine gegebene Ressource erzeugen kann
  • Intermediary (Vermittler): Proxy, Gateway oder Tunnel
  • Cache (Zwischenspeicher): Lokale Speicherung früherer Antworten

Nachrichtenstruktur​

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

Anforderungsbeispiel​

GET /hello.txt HTTP/1.1
Host: www.example.com
User-Agent: curl/7.16.3
Accept-Language: de, en

Antwortbeispiel​

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Content-Length: 51
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

Wichtige Merkmale​

  1. Zustandsloses Protokoll – Jede Anforderung wird unabhängig verarbeitet
  2. Persistente Verbindungen – HTTP/1.1 verwendet standardmäßig persistente Verbindungen
  3. Chunked Transfer Encoding – Ermöglicht das Senden von Daten ohne Kenntnis der Gesamtlänge
  4. Vermittlerunterstützung – Unterstützt Proxys, Gateways und Tunnel
  5. Protokoll-Upgrade – Unterstützt das Upgrade auf andere Protokolle (z. B. WebSocket)

Sicherheitsüberlegungen​

  1. Eingabevalidierung – Benutzereingaben stets validieren und bereinigen
  2. Längenbeschränkungen – Beschränkungen für Anforderungszeilen- und Header-Feldlängen implementieren
  3. HTTPS verwenden – TLS-Verschlüsselung für sensible Kommunikation einsetzen
  4. Request Smuggling verhindern – Nachrichtenparse-Regeln strikt einhalten
  5. Vermittlersicherheit – Proxys und Gateways sorgfältig behandeln
  6. Datenschutz – Personenbezogene Daten in Server-Protokollen schützen

Urheberrechtshinweis​

Copyright © 2014 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust.

Verwandte Ressourcen​

📌 Lesen beginnen: Beginnen Sie mit Abschnitt 1 – Einführung

1. Introduction (Einführung)​

Das Hypertext Transfer Protocol (HTTP, Hypertext-Übertragungsprotokoll) ist ein zustandsloses Anfrage/Antwort-Protokoll, das durch den Austausch von Nachrichten über eine zuverlässige Transport- oder Session-Layer-Verbindung funktioniert. Dieses Dokument ist der erste Teil einer Dokumentreihe, die HTTP/1.1 definiert.

Der Hauptinhalt dieses Dokuments umfasst:

  • Eine Übersicht über die HTTP-Architektur und die zugehörige Terminologie
  • Die Definition der "http" und "https" Uniform Resource Identifier (URI, Einheitlicher Ressourcenbezeichner) Schemata
  • Die HTTP/1.1-Nachrichtensyntax und Parsing-Anforderungen
  • Sicherheitsüberlegungen bezüglich der Implementierung

Die HTTP/1.1-Nachrichtensyntax und Parsing-Anforderungen wurden gegenüber RFC 2616 überarbeitet, um die Interoperabilität zu verbessern und bekannte Mehrdeutigkeiten zu reduzieren. Dieses Dokument ersetzt bestimmte Teile von RFC 2616 und wird zusammen mit anderen Dokumenten verwendet, die die HTTP/1.1-Semantik definieren.

Die anderen Teile von HTTP sind in den folgenden unabhängigen Dokumenten definiert:

  1. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" [RFC7231] - definiert Anfragemethoden, Statuscodes und andere mit der Protokollsemantik zusammenhängende Elemente
  2. "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" [RFC7232] - definiert Mechanismen für bedingte Anfragen
  3. "Hypertext Transfer Protocol (HTTP/1.1): Range Requests" [RFC7233] - definiert Teilanfragen und -antworten
  4. "Hypertext Transfer Protocol (HTTP/1.1): Caching" [RFC7234] - definiert Cache-Anforderungen und -Steuerung
  5. "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235] - definiert das Benutzerauthentifizierungs-Framework

1.1. Requirements Notation (Anforderungsnotation)​

Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "SOLL NICHT", "SOLLTE", "SOLLTE NICHT", "EMPFOHLEN", "KANN" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

Konformitätskriterien und Überlegungen werden in Section 2.5 beschrieben.

1.2. Syntax Notation (Syntaxnotation)​

Diese Spezifikation verwendet die Augmented Backus-Naur Form (ABNF, Erweiterte Backus-Naur-Form) Notation von [RFC5234] mit einer Listenerweiterung, die in Section 7 definiert ist und die kompakte Definition von durch Kommas getrennten Listen unter Verwendung eines #-Operators ermöglicht.

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

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

2. Architecture (Architektur)​

HTTP wurde als zustandsloses Kommunikationsprotokoll auf Anwendungsebene entwickelt, das für viele Aufgaben über seine Verwendung für Hypertext hinaus genutzt werden kann, wie z.B. für Namensserver und verteilte Objektverwaltungssysteme, durch Erweiterung seiner Anfragemethoden, Fehlercodes und Header.

2.1. Client/Server Messaging (Client/Server-Nachrichtenaustausch)​

HTTP ist ein zustandsloses Anfrage/Antwort-Protokoll. Ein Client sendet eine Anfrage in Form einer Anfragenachricht an einen Server. Der Server antwortet mit einer Antwortnachricht.

Die Terminologie "Client" und "Server" bezieht sich nur auf die Rollen, die diese Programme für eine bestimmte Verbindung übernehmen. Dasselbe Programm kann bei einigen Verbindungen als Client und bei anderen als Server fungieren.

2.2. Implementation Diversity (Implementierungsvielfalt)​

HTTP ist so konzipiert, dass es die Implementierungsdetails seiner Teilnehmer verbirgt. Daher kann HTTP mit vielen verschiedenen Transport-Protokollen niedrigerer Ebenen verwendet werden.

2.3. Intermediaries (Vermittler)​

HTTP-Vermittler sind Komponenten, die zwischen Client und Server liegen und als Nachrichtenübertragungsagenten fungieren.

Es gibt drei gängige Arten von HTTP-Vermittlern:

Proxy (Proxy)​

Ein Proxy ist ein vom Client ausgewählter Nachrichtenübertragungsagent, normalerweise durch lokale Konfiguration, um Anfragen für bestimmte Arten von absoluten URIs zu empfangen und zu versuchen, diese Anfragen durch Übersetzung zu erfüllen, falls erforderlich.

Gateway (Gateway)​

Ein Gateway (auch als Reverse-Proxy bekannt) ist ein Nachrichtenübertragungsagent, der als Ursprungsserver für die eingehende Anfrage fungiert, aber empfangene Anfragen übersetzt und an einen anderen Server (oder Server) weiterleitet.

Tunnel (Tunnel)​

Ein Tunnel fungiert als Relay zwischen zwei Verbindungen, ohne die Nachrichten zu ändern. Ein Tunnel hört auf zu existieren, wenn beide Enden der weitergeleiteten Verbindung geschlossen sind.

2.4. Caches (Caches)​

Ein Cache ist ein lokaler Speicher für Antwortnachrichten und das Subsystem, das deren Speicherung, Abruf und Löschung steuert. Ein Cache speichert Antworten auf Anfragen, um die Antwortzeit und den Netzwerkbandbreitenverbrauch bei zukünftigen äquivalenten Anfragen zu reduzieren.

2.5. Conformance and Error Handling (Konformität und Fehlerbehandlung)​

Das Schlüsselwort "MUST" (MUSS) oder die Begriffe "REQUIRED" (ERFORDERLICH) oder "SHALL" (MUSS) bedeuten, dass eine Definition eine absolute Anforderung der Spezifikation ist.

Das Schlüsselwort "MUST NOT" (DARF NICHT) oder der Ausdruck "SHALL NOT" (DARF NICHT) bedeuten, dass eine Definition ein absolutes Verbot der Spezifikation ist.

Das Schlüsselwort "SHOULD" (SOLLTE) oder das Adjektiv "RECOMMENDED" (EMPFOHLEN) bedeuten, dass es unter bestimmten Umständen triftige Gründe geben kann, ein bestimmtes Element zu ignorieren, aber alle Implikationen müssen verstanden und sorgfältig abgewogen werden, bevor ein anderer Kurs gewählt wird.

Das Schlüsselwort "SHOULD NOT" (SOLLTE NICHT) oder der Ausdruck "NOT RECOMMENDED" (NICHT EMPFOHLEN) bedeuten, dass unter bestimmten Umständen triftige Gründe existieren können, wenn das bestimmte Verhalten akzeptabel oder sogar nützlich ist.

Das Schlüsselwort "MAY" (KANN) oder das Adjektiv "OPTIONAL" (OPTIONAL) bedeuten, dass ein Element wirklich optional ist.

2.6. Protocol Versioning (Protokollversionierung)​

HTTP verwendet ein Versionsnummerierungsschema "<major>.<minor>", um Protokollversionen anzugeben. Dieses Dokument definiert HTTP/1.1.

2.7. Uniform Resource Identifiers (Einheitliche Ressourcenkennungen)​

Uniform Resource Identifiers (URI) [RFC3986] werden in HTTP verwendet, um Ressourcen zu identifizieren. URI-Referenzen werden verwendet, um Anfragen zu zielen, Umleitungen anzuzeigen und Beziehungen zu definieren.

URI-reference = <URI-reference, siehe [RFC3986], Section 4.1>
absolute-URI  = <absolute-URI, siehe [RFC3986], Section 4.3>
relative-part = <relative-part, siehe [RFC3986], Section 4.2>
authority     = <authority, siehe [RFC3986], Section 3.2>
uri-host      = <host, siehe [RFC3986], Section 3.2.2>
port          = <port, siehe [RFC3986], Section 3.2.3>
path-abempty  = <path-abempty, siehe [RFC3986], Section 3.3>
segment       = <segment, siehe [RFC3986], Section 3.3>
query         = <query, siehe [RFC3986], Section 3.4>

2.7.1. http URI Scheme (http-URI-Schema)​

Das "http"-Schema wird verwendet, um Netzwerkressourcen über das HTTP-Protokoll zu lokalisieren.

http-URI = "http://" authority path-abempty [ "?" query ]
           [ "#" fragment ]

2.7.2. https URI Scheme (https-URI-Schema)​

Das "https"-Schema wird verwendet, um Netzwerkressourcen über das HTTP-Protokoll über eine gesicherte Verbindung zu lokalisieren.

https-URI = "https://" authority path-abempty [ "?" query ]
            [ "#" fragment ]

2.7.3. http and https URI Normalization and Comparison (HTTP- und HTTPS-URI-Normalisierung und -Vergleich)​

HTTP- und HTTPS-URIs werden auf die gleiche Weise wie alle anderen URIs verglichen.

3. Message Format (Nachrichtenformat)​

Alle HTTP-Nachrichten bestehen aus einer Startzeile, gefolgt von einer Byte-Sequenz mit einer Syntax ähnlich dem Internet Message Format [RFC5322]: null oder mehr Header-Felder (kollektiv als "Header" oder "Header-Abschnitt" bezeichnet), eine Leerzeile, die das Ende des Header-Abschnitts anzeigt, und ein optionaler Nachrichtenkörper.

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

3.1. Start Line (Startzeile)​

Eine HTTP-Nachricht beginnt mit einer Startzeile (start-line).

start-line     = request-line / status-line

3.1.1. Request Line (Anfrage zeile)​

Eine Anfragezeile (request-line) beginnt mit einem Methoden-Token, gefolgt von einem Anfrageziel, einer Protokollversion und endet mit CRLF.

request-line   = method SP request-target SP HTTP-version CRLF
method         = token

3.1.2. Status Line (Statuszeile)​

Die erste Zeile einer Antwortnachricht ist die Statuszeile (status-line), bestehend aus der Protokollversion, einem Leerzeichen, einem Statuscode, einem weiteren Leerzeichen, einer möglicherweise leeren Begründungsphrase und endend mit CRLF.

status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

3.2. Header Fields (Header-Felder)​

Jedes Header-Feld besteht aus einem case-insensitiven Feldnamen, gefolgt von einem Doppelpunkt (":"), optionalem Whitespace, dem Feldwert und optionalem Whitespace.

header-field   = field-name ":" OWS field-value OWS
field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text
obs-fold       = CRLF 1*( SP / HTAB )

3.2.1. Field Extensibility (Felderweiterbarkeit)​

Header-Felder sind vollständig erweiterbar: Es gibt keine Begrenzung für die Anzahl der Header-Felder, die in einer Nachricht verwendet werden können.

3.2.2. Field Order (Feldreihenfolge)​

Die Reihenfolge, in der Header-Felder mit unterschiedlichen Feldnamen empfangen werden, ist nicht signifikant.

3.2.3. Whitespace (Leerzeichen)​

Optionales Whitespace (OWS) wird nur verwendet, um die Lesbarkeit zu verbessern.

OWS            = *( SP / HTAB )
RWS            = 1*( SP / HTAB )
BWS            = OWS

3.2.4. Field Parsing (Feld-Parsing)​

Nachrichten werden mit einem allgemeinen Ansatz geparst, der unabhängig von einzelnen Feldnamen ist.

3.2.5. Field Limits (Feldbegrenzungen)​

HTTP-Implementierungen legen keine vordefinierten Grenzen für die Länge jedes Header-Felds oder auf die Länge des Header-Abschnitts als Ganzes fest.

3.2.6. Field Value Components (Feldwertkomponenten)​

Die meisten HTTP-Header-Feldwerte werden mithilfe einer gemeinsamen Grammatik von Feldwerttypen definiert.

token          = 1*tchar
tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "0"-"9" / "A"-"Z" / "^" / "_"
               / "`" / "a"-"z" / "|" / "~"
quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP / "!" / %x23-5B / %x5D-7E / obs-text
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
comment        = "(" *( ctext / quoted-pair / comment ) ")"
ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

3.3. Message Body (Nachrichtenkörper)​

Der Nachrichtenkörper (message-body, falls vorhanden) einer HTTP-Nachricht wird verwendet, um die Nutzlast (Payload) der Nachricht zu übertragen.

message-body = *OCTET

3.3.1. Transfer-Encoding​

Der Transfer-Encoding-Header listet die Transferkodierungsnamen auf, die der Sequenz von Transferkodierungen entsprechen, die auf die Nutzlast angewendet wurden (oder werden), um den Nachrichtenkörper zu bilden.

Transfer-Encoding = 1#transfer-coding

Ein Server MUSS einen Statuscode 400 (Bad Request, Ungültige Anfrage) für jede empfangene Anfrage generieren, die sowohl einen Content-Length- als auch einen Transfer-Encoding-Header enthält.

3.3.2. Content-Length​

Der Content-Length-Header gibt die erwartete Länge des Nachrichtenkörpers in Oktetten an.

Content-Length = 1*DIGIT

3.3.3. Message Body Length (Nachrichtenkörperlänge)​

Die Länge eines Nachrichtenkörpers wird durch eines der folgenden Elemente bestimmt (in Prioritätsreihenfolge):

  1. Jede Antwort auf eine HEAD-Anfrage und jede Antwort mit einem Statuscode 1xx (Informational, Informativ), 204 (No Content, Kein Inhalt) oder 304 (Not Modified, Nicht Geändert) wird immer durch die erste Leerzeile nach den Header-Feldern beendet.

  2. Wenn ein Transfer-Encoding-Header vorhanden ist und der chunked-Transferkodierungswert der Endwert ist, dann besteht der Nachrichtenkörper aus einem oder mehreren Chunks.

  3. Wenn ein Content-Length-Header vorhanden ist, repräsentiert sein Dezimalwert in Oktetten sowohl die Nutzlastlänge als auch die Nachrichtenkörperlänge.

  4. Wenn die Nachricht die "multipart/byteranges"-Transferkodierung verwendet und der Content-Length-Header nicht anders angegeben ist, dann definiert dieser selbst-delimierende Medientyp die Nachrichtenkörperlänge.

  5. Durch Schließen der Verbindung durch den Server.

3.4. Handling Incomplete Messages (Behandlung unvollständiger Nachrichten)​

Ein Server, der eine unvollständige Anfragenachricht erhält, normalerweise aufgrund einer vorzeitig geschlossenen Verbindung, MUSS mit einem Statuscode 400 (Bad Request, Ungültige Anfrage) antworten.

3.5. Message Parsing Robustness (Robustheit des Nachrichten-Parsings)​

Obwohl die Anforderungen dieses Dokuments in Begriffen strenger Konformität ausgedrückt werden, werden Implementierungen ermutigt, beim Parsing tolerant zu sein.

4. Transfer Codings (Übertragungskodierungen)​

Transferkodierungsnamen (Transfer coding) werden verwendet, um Kodierungstransformationen anzuzeigen, die auf den Nutzlastkörper angewendet wurden, angewendet werden können oder angewendet werden müssen, um eine "sichere Übertragung" über das Netzwerk zu gewährleisten.

transfer-coding    = "chunked"
                   / "compress"
                   / "deflate"
                   / "gzip"
                   / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )

4.1. Chunked Transfer Coding (Chunked-Übertragungskodierung)​

Die Chunked-Übertragungskodierung (chunked transfer coding) umhüllt den Nutzlastkörper in eine Reihe von Chunks, wobei jeder Chunk seinen eigenen Größenindikator hat, gefolgt von einem optionalen Trailer-Abschnitt, der Trailer-Felder enthält.

chunked-body   = *chunk
                 last-chunk
                 trailer-part
                 CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF
chunk-data     = 1*OCTET

Das chunk-size-Feld ist eine Zeichenkette aus Hexadezimalziffern, die die Größe der Chunk-Daten (in Oktetten) angibt.

Ein Empfänger MUSS in der Lage sein, die Chunked-Übertragungskodierung zu parsen und zu dekodieren.

4.1.1. Chunk Extensions (Chunk-Erweiterungen)​

Die Chunked-Übertragungskodierung ermöglicht die Aufnahme von null oder mehr Chunk-Erweiterungen (chunk extensions) in jedem Chunk.

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token / quoted-string

4.1.2. Chunked Trailer Part (Chunked-Trailer-Teil)​

Ein Trailer ermöglicht es dem Absender, zusätzliche Header-Felder am Ende einer ge chunkten Nachricht einzuschließen, um Metadaten bereitzustellen, die während des Sendens des Nachrichtenkörpers dynamisch generiert werden können.

trailer-part   = *( header-field CRLF )

Ein Absender DARF NICHT ein Transfer-Encoding-, Content-Length- oder Trailer-Feld in einem Trailer generieren.

4.1.3. Decoding Chunked (Dekodieren von Chunked)​

Der Prozess zum Dekodieren der Chunked-Übertragungskodierung kann wie folgt implementiert werden (unter Verwendung von Pseudocode):

length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
   read chunk-data and CRLF
   append chunk-data to decoded-body
   length := length + chunk-size
   read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
   if (trailer field is allowed to be sent in a trailer) {
      append trailer field to existing header fields
   }
   read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding

4.2. Compression Codings (Kompressionskodierungen)​

Die folgenden drei Kompressionskodierungsnamen sind aus Kompatibilitätsgründen mit HTTP/1.0 definiert.

4.2.1. Compress Coding (Compress-Kodierung)​

Die "compress"-Kodierung ist eine adaptive Lempel-Ziv-Welch (LZW)-Kodierung [Welch], die normalerweise vom UNIX-Dateikomprimierungsprogramm "compress" erzeugt wird.

4.2.2. Deflate Coding (Deflate-Kodierung)​

Die "deflate"-Kodierung ist ein "zlib"-Datenformat [RFC1950], das einen "deflate"-komprimierten Datenstrom [RFC1951] enthält, der eine Kombination aus dem Lempel-Ziv (LZ77)-Kompressionsalgorithmus und Huffman-Kodierung verwendet.

4.2.3. Gzip Coding (Gzip-Kodierung)​

Die "gzip"-Kodierung ist eine LZ77-Kodierung mit einer 32-Bit-Zyklischen Redundanzprüfung (CRC), die normalerweise vom gzip-Dateikomprimierungsprogramm [RFC1952] erzeugt wird.

4.3. TE​

Der TE-Header zeigt an, welche Übertragungskodierungen außer Chunked der Client bereit ist, in der Antwort zu akzeptieren, und ob der Client bereit ist, Trailer-Felder zu akzeptieren.

TE        = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] )
          / ( "1" [ "." 0*3("0") ] )

4.4. Trailer​

Wenn der Absender weiß, welche Header-Felder im Trailer-Abschnitt des letzten Chunks gesendet werden, dann SOLLTE der Absender ein Trailer-Header-Feld senden, das eine Liste dieser Header-Feldnamen enthält.

Trailer = 1#field-name

5. Message Routing (Nachrichten-Routing)​

Das Routing einer HTTP-Anfragenachricht wird vom Client basierend auf der Zielressource, der Proxy-Konfiguration und der Einrichtung oder Wiederverwendung einer Netzwerkverbindung bestimmt.

5.1. Identifying a Target Resource (Identifizierung einer Zielressource)​

HTTP begrenzt nicht, wie viele verschiedene Ressourcen ein einzelner Ursprungsserver autoritative Antworten bereitstellen kann, noch den Umfang der Autorität einer einzelnen Ressource oder den URI-Raum, auf den eine einzelne Ressource verweisen kann.

5.2. Connecting Inbound (Eingehende Verbindung)​

Sobald der Client die Ziel-URI und den Ursprungsserver oder Proxy durch Untersuchen der URI oder seiner Konfiguration bestimmt hat, bestimmt der Client, wohin er sich verbinden soll.

5.3. Request Target (Anfrageziel)​

Sobald eine eingehende Verbindung zum Ziel hergestellt ist, sendet der Client eine HTTP-Anfragenachricht (Section 3) mit einer start-line, die ein request-target (Anfrageziel) enthält, das die Zielressource identifiziert, auf die die Anfrage angewendet werden soll.

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

5.3.1. origin-form​

Die häufigste Form des Anfrageziels ist "origin-form".

origin-form    = absolute-path [ "?" query ]

5.3.2. absolute-form​

Beim Senden einer Anfrage an einen Proxy, mit Ausnahme von CONNECT-Anfragen oder server-weiten OPTIONS-Anfragen (unten beschrieben), MUSS ein Client die absolute-form der Ziel-URI als Anfrageziel senden.

absolute-form  = absolute-URI

5.3.3. authority-form​

Das authority-form-Anfrageziel wird nur für CONNECT-Anfragen ([RFC7231], [Section 4.3.6]) verwendet.

authority-form = authority

5.3.4. asterisk-form​

Das asterisk-form-Anfrageziel wird nur für server-weite OPTIONS-Anfragen ([RFC7231], [Section 4.3.7]) verwendet.

asterisk-form  = "*"

5.4. Host​

Der Host-Header liefert die Host- und Port-Informationen der Ziel-URI in einer Anfrage und ermöglicht es dem Ursprungsserver, Ressourcen zu unterscheiden, die über eine einzelne IP-Adresse bereitgestellt werden.

Host = uri-host [ ":" port ]

Ein Client MUSS ein Host-Header-Feld in allen HTTP/1.1-Anfragenachrichten senden.

5.5. Effective Request URI (Effektive Anfrage-URI)​

Wenn das Anfrageziel in absolute-form vorliegt, ist die effektive Anfrage-URI (effective request URI) das Anfrageziel.

5.6. Associating a Response to a Request (Zuordnung einer Antwort zu einer Anfrage)​

HTTP enthält keine Identifikatoren in Antworten, um eine Antwort explizit einer bestimmten Anfrage zuzuordnen. Daher verlässt es sich auf die zugrunde liegende Verbindung, um zu identifizieren, welche Anfrage mit einer Antwort verbunden ist.

5.7. Message Forwarding (Nachrichtenweiterleitung)​

Wie in Section 2.3 beschrieben, können Vermittler als Proxy für einen ausgehenden Server fungieren, als Gateway, das als Repräsentation eines Ursprungsservers fungiert, oder als Tunnel, der als Verbindungsrelay fungiert.

5.7.1. Via​

Der Via-Header zeigt das Vorhandensein von intermediären Protokollen und Empfängern zwischen der Anfragenachricht und der Antwortnachricht an.

Via = 1#( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( uri-host [ ":" port ] ) / pseudonym
pseudonym         = token

Jeder Vermittler MUSS ein Via-Header-Feld hinzufügen, bevor er die Nachricht weiterleitet.

5.7.2. Transformations (Transformationen)​

Einige Vermittler umfassen Transformationsfunktionen für die Nutzlast oder die Nachrichtensemantik, die für einige HTTP-Anwendungen nützlich sein können.

Ein Proxy SOLLTE den Absichtsinhalt (intent content) einer Anfrage nicht ändern, es sei denn, dies wird ausdrücklich angefordert.

6. Connection Management (Verbindungsmanagement)​

Die HTTP-Nachrichtenübertragung ist unabhängig von den zugrunde liegenden Transport- oder Sitzungsschicht-Verbindungsprotokollen. HTTP setzt nur einen zuverlässigen Transport voraus, der eine geordnete Zustellung von Anfragen und Antworten bieten kann.

6.1. Connection​

Der Connection-Header ermöglicht es dem Absender, gewünschte Steueroptionen für die aktuelle Verbindung anzugeben.

Connection        = 1#connection-option
connection-option = token

6.2. Establishment (Einrichtung)​

Der Client ist für die Einrichtung einer Verbindung zum Server verantwortlich. HTTP hat keine Anforderungen an das Nachrichtenframing zur Einrichtung oder Identifizierung der Verbindung selbst.

6.3. Persistence (Persistenz)​

HTTP/1.1 verwendet standardmäßig "persistente Verbindungen" (persistent connections), die es ermöglichen, mehrere Anfragen und Antworten über eine einzelne Verbindung zu senden. HTTP-Implementierungen SOLLTEN persistente Verbindungen unterstützen.

6.3.1. Retrying Requests (Wiederholung von Anfragen)​

Beim automatischen Wiederholen einer Anfrage kann die Verbindung während der Übertragung der Anfragenachricht (oder während des Wartens auf die Antwortnachricht) fehlschlagen. Ein Client SOLLTE eine Anfrage nicht automatisch wiederholen, es sei denn, er kann bestätigen, dass die Anfrage idempotent ist ([RFC7231], [Section 4.2.2]) oder er erhält eine Nachricht vom Ursprungsserver, die anzeigt, dass der Server die Anfrage vor dem Verbindungsfehler nicht verarbeitet hat.

6.3.2. Pipelining (Pipelining)​

Ein Client, der persistente Verbindungen unterstützt, KANN Anfragen "pipelinen" (d.h. mehrere Anfragen senden, ohne auf jede Antwort zu warten). Ein Server MUSS seine Antworten auf diese gepipelineten Anfragen in der gleichen Reihenfolge senden, in der die Anfragen empfangen wurden.

6.4. Concurrency (Nebenläufigkeit)​

Ein Client SOLLTE die Anzahl gleichzeitiger Verbindungen, die er zu einem Server aufbaut, begrenzen.

6.5. Failures and Timeouts (Fehler und Timeouts)​

Server haben normalerweise einen Timeout-Wert, nach dem sie eine inaktive Verbindung nicht mehr aufrechterhalten. Proxy-Server können kürzere Timeout-Werte verwenden, um Ressourcen zu schonen.

6.6. Tear-down (Abbau)​

Der Connection-Header (Section 6.1) bietet eine "close"-Verbindungsoption, die der Absender verwendet, um zu signalisieren, dass die Verbindung nach Abschluss der aktuellen Anfrage/Antwort geschlossen wird.

6.6.1. Retrying Requests (Wiederholung von Anfragen)​

Ein Client SOLLTE eine idempotente Anfrage wiederholen, wenn die Verbindung nach dem Senden der Anfrage geschlossen wird (selbst wenn der Client zuvor Anfragen über diese Verbindung gesendet hatte).

6.6.2. Closure (Schließung)​

Wenn ein Server ein sofortiges Schließen einer TCP-Verbindung durchführt, besteht ein erhebliches Risiko, dass der Client die letzte HTTP-Antwort nicht lesen kann.

6.7. Upgrade (Upgrade)​

Der Upgrade-Header bietet einen einfachen Mechanismus für den Übergang von HTTP/1.1 zu anderen inkompatiblen Protokollen.

Upgrade          = 1#protocol
protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Ein Server KANN das Protokoll wechseln, indem er eine 101 (Switching Protocols, Protokollwechsel)-Antwort sendet.

7. ABNF List Extension: #rule (ABNF-Listen-Erweiterung: #Regel)​

Die in der ABNF-Notation von [RFC5234] definierten Syntaxregeln sind eine gemeinsame Struktur für HTTP-Header-Felder. Dieser Abschnitt definiert die #-Konstruktion, die zur Definition von durch Komma getrennten Listenelementen verwendet wird.

Eine Konstruktion, die den #-Operator verwendet, funktioniert genauso wie eine, die den *-Operator verwendet, außer dass mindestens ein Listenelement erforderlich ist und Listenelemente durch ein oder mehrere Kommas (",") und optionalen Whitespace (OWS) getrennt sind.

#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

Ein Absender SOLLTE NICHT leere Listenelemente generieren. Ein Absender MUSS Listen mit mindestens einem nicht leeren Element generieren.

8. IANA Considerations (IANA-Betrachtungen)​

8.1. Header Field Registration (Header-Feld-Registrierung)​

HTTP-Header-Felder sind im "Message Headers"-Register eingetragen, das unter http://www.iana.org/assignments/message-headers/ gepflegt wird.

Dieses Dokument definiert die folgenden HTTP-Header-Felder, daher wurde das "Permanent Message Header Field Names"-Register gemäß [RFC3864] aktualisiert:

Header Field NameProtocolStatusReference
ConnectionhttpstandardSection 6.1
Content-LengthhttpstandardSection 3.3.2
HosthttpstandardSection 5.4
TEhttpstandardSection 4.3
TrailerhttpstandardSection 4.4
Transfer-EncodinghttpstandardSection 3.3.1
UpgradehttpstandardSection 6.7
ViahttpstandardSection 5.7.1

8.2. URI Scheme Registration (URI-Schema-Registrierung)​

Die IANA hat die Registrierung der "http"- und "https"-URI-Schemata (ursprünglich in [RFC2617] und [RFC2818] definiert) aktualisiert, um auf diese Spezifikation zu verweisen.

8.3. Internet Media Type application/http​

Die IANA hat die Registrierung des "application/http"-Medientyps (ursprünglich in [RFC2616] definiert) aktualisiert, um auf diese Spezifikation zu verweisen.

8.4. Transfer Coding Registry (Transferkodierungs-Register)​

Das Register für Transferkodierungsnamen wird unter http://www.iana.org/assignments/http-parameters/ gepflegt.

Dieses Dokument registriert die folgenden Transferkodierungen:

NameDescriptionReference
chunkedChunked-ÜbertragungskodierungSection 4.1
compressUNIX "compress"-DatenformatSection 4.2.1
deflate"deflate"-komprimiertes DatenformatSection 4.2.2
gzipGZIP-DateiformatSection 4.2.3

8.5. Content Coding Registry (Inhaltskodierungs-Register)​

Das Register für Inhaltskodierungsnamen wird unter http://www.iana.org/assignments/http-parameters/ gepflegt.

8.6. Upgrade Token Registry (Upgrade-Token-Register)​

Das HTTP-Upgrade-Token-Register definiert den Namensraum für Namen, die im Upgrade-Header (Section 6.7) verwendet werden.

9. Security Considerations (Sicherheitsbetrachtungen)​

Dieser Abschnitt zielt darauf ab, Entwickler, Informationsanbieter und Benutzer über bekannte Sicherheitsbeschränkungen bei der Bereitstellung von HTTP/1.1 zu informieren.

9.1. Establishing Authority (Einrichtung der Autorität)​

HTTP stützt sich auf das Konzept der Authority-Komponente (Autorität) einer URI, die die IP-Adresse oder den Hostnamen eines Ursprungsservers und die TCP-Portnummer umfasst.

Der Bedarf an einem vertrauenswürdigen Mechanismus zur Einrichtung der Server-Autorität innerhalb von HTTP führte zur Entwicklung von HTTPS (HTTP über TLS), wie in [RFC2818] definiert.

9.2. Risks of Intermediaries (Risiken von Vermittlern)​

Standardmäßig stützt sich HTTP auf die Sicherheitsattribute des zugrunde liegenden Transportprotokolls. Durch die Verwendung von TLS verlässt sich HTTP auf TLS, um die Identität zu überprüfen und Vertraulichkeits- und Integritätsschutz bereitzustellen.

TLS bietet jedoch nur Schutz auf der Transportschicht. HTTP-Nachrichten können von Vermittlern gelesen oder geändert werden, die keine Endpunkte auf dem Kommunikationspfad sind.

9.3. Attacks Based on File and Path Names (Angriffe auf Datei- und Pfadnamen)​

Ursprungsserver verwenden oft eine hierarchische Dateisystemverzeichnisstruktur zum Speichern von Ressourcendarstellungen und spiegeln diese Hierarchie im von ihnen bereitgestellten URI-Raum wider.

Implementierungen müssen darauf achten, wie sie URIs auf das Dateisystem abbilden.

9.4. Attacks Based on Command, Code, or Query Injection (Angriffe basierend auf Befehls-, Code- oder Abfrage-Injektion)​

Ursprungsserver verwenden häufig vom Client bereitgestellte Parameter (in der URI oder im Nachrichtenkörper), und diese Parameter werden manchmal verwendet, um interne Abfragen, Befehle oder Code zu konstruieren.

Implementierungen MÜSSEN alle Eingaben validieren und bereinigen.

9.5. Attacks via Protocol Element Length (Angriffe über Protokollelementlänge)​

Da HTTP längenbasierte Begrenzer verwendet, um die Grenzen verschiedener Protokollelemente zu markieren, einschließlich Anfragezeile, Statuszeile, Header-Felder und Nachrichtenkörper, müssen Implementierungen verhindern, dass ein Angreifer übermäßige Ressourcen verbraucht, indem er übermäßig große Protokollelemente sendet.

9.5.1. Request Smuggling (Anfrage-Smuggling)​

Request-Smuggling-Angriffe nutzen Inkonsistenzen oder Mehrdeutigkeiten im HTTP-Nachrichtenframing aus.

Um Request-Smuggling-Angriffe zu verhindern, MÜSSEN Implementierungen:

  • Die Nachrichtenframing-Regeln strikt einhalten, insbesondere die in Section 3.3.3 definierten Regeln zur Bestimmung der Nachrichtenkörperlänge
  • Nachrichten ablehnen, die inkonsistente oder mehrdeutige Framing-Informationen enthalten

9.5.2. Response Splitting (Antwort-Splitting)​

Response-Splitting-Angriffe nutzen eine Schwachstelle aus, bei der eine Anwendung Eingaben beim Generieren von HTTP-Antworten nicht ordnungsgemäß validiert.

Implementierungen MÜSSEN alle Eingaben validieren.

9.6. Disclosure of Sensitive Information in URIs (Offenlegung sensibler Informationen in URIs)​

URIs werden häufig in verschiedenen Systemprotokollen, Browserverlauf und Referer-Header-Feldern protokolliert. Daher SOLLTEN sensible Informationen NICHT in URIs übertragen werden, insbesondere nicht in Abfragezeichenfolgen.

9.7. Disclosure of Fragment after Redirects (Offenlegung von Fragment nach Weiterleitungen)​

Obwohl Fragment-Identifikatoren nicht an Server gesendet werden, kann das ursprüngliche Fragment nach der Weiterleitung der neuen Site offengelegt werden, wenn eine URI ein Fragment enthält und diese URI zu einer anderen Site weitergeleitet wird.

9.8. Disclosure of Product Information (Offenlegung von Produktinformationen)​

Die Server- und User-Agent-Header enthalten normalerweise Informationen über die Software des Absenders. Obwohl diese Informationen für statistische Zwecke und zur Identifizierung von Interoperabilitätsproblemen nützlich sein können, können sie auch von einem Angreifer verwendet werden, um Software-Schwachstellen zu identifizieren.

9.9. Browser Fingerprinting (Browser-Fingerprinting)​

Browser-Fingerprinting ist eine Technik, bei der eine Website verschiedene Informationen (einschließlich HTTP-Header-Felder) verwendet, um einen Browser eindeutig zu identifizieren oder zu verfolgen, auch ohne Verwendung von Cookies oder anderen expliziten Tracking-Mechanismen.

Acknowledgments (Danksagungen)​

Wir danken allen Personen, die zur Entwicklung der HTTP/1.1-Spezifikation beigetragen haben.

Wir danken den vielen Personen, die direkt oder indirekt zur Erstellung dieses Dokuments beigetragen haben:

  • Roy T. Fielding (Hauptherausgeber der Spezifikation)
  • Julian Reschke (Co-Herausgeber der Spezifikation)
  • Alle Mitglieder der HTTP-Arbeitsgruppe

Wir danken auch den Autoren der vorherigen HTTP-Spezifikation ([RFC2616]): Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Frystyk, Larry Masinter, Paul Leach, Tim Berners-Lee.

Wir danken allen Anbietern, Entwicklern und Benutzern, die zur Implementierung und zum Testen von HTTP/1.1 beigetragen haben.

References (Referenzen)​

Normative References (Normative Referenzen)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

  • [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

  • [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

  • [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.

  • [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

Informative References (Informative Referenzen)​

  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

  • [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.

  • [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.

  • [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.

  • [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

  • [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

  • [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997.

  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

  • [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.

  • [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

  • [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.

  • [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

  • [Welch] Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.

Appendix A. HTTP Version History (HTTP-Versionshistorie)​

Die HTTP-Versionierungspolitik hat sich nicht geändert, seit sie erstmals 1990 als Teil der World-Wide Web Global Information Initiative eingeführt wurde. Diese Versionspolitik zielt darauf ab, dem Absender zu ermöglichen, das Format einer Nachricht und seine Fähigkeit anzuzeigen, weitere Kommunikation zu verstehen und daran teilzunehmen.

Die Entwicklung von HTTP/1.1 dauerte über 10 Jahre, einschließlich zweier verschiedener Standards-Track-Spezifikationen ([RFC2068] und [RFC2616]) sowie Jahrzehnten an Implementierungs- und Bereitstellungserfahrung.

A.1. HTTP/0.9​

HTTP/0.9 war die erste Implementierung des HTTP-Protokolls im World-Wide Web. Es war ein einfaches Protokoll, bei dem eine Anfrage aus einer einzigen Zeile bestand, die nur die Methode und die Ziel-URI enthielt.

GET /hello.txt

A.1.1. HTTP/1.0​

HTTP/1.0 dokumentierte das gemeinsame HTTP-Nachrichtenformat. Es fügte eine Protokollversionsnummer, einen Statuscode und einen Header-Abschnitt für sowohl Anfragen als auch Antworten hinzu.

Die HTTP/1.0-Spezifikation ist in [RFC1945] definiert.

A.1.2. HTTP/1.1​

HTTP/1.1 ist eine Verfeinerung von HTTP/1.0, einschließlich detaillierter Beschreibungen von Anfragemethoden, Antwortstatuscodes und Header-Feldern.

Die Hauptverbesserungen umfassen:

  • Persistente Verbindungen: Verbindungen sind standardmäßig persistent
  • Chunked-Übertragungskodierung: Ermöglicht dynamisches Senden des Nachrichtenkörpers
  • Host-Header: Unterstützung für virtuelles Hosting
  • Pipelining: Ermöglicht paralleles Senden mehrerer Anfragen
  • Cache-Steuerung: Ausgeklügeltere Caching-Mechanismen

HTTP/1.1 wurde zuerst in [RFC2068] (Januar 1997) definiert und dann in [RFC2616] (Juni 1999) aktualisiert.

A.2. Changes from RFC 2616 (Änderungen gegenüber RFC 2616)​

Dieses Dokument ([RFC7230]) ersetzt das vorherige [RFC2616] und führt viele Klarstellungen und Verbesserungen ein:

A.2.1. Architecture (Architektur)​

  • Klarstellung der Rollen von Vermittlern (Proxys, Gateways, Tunnels)
  • Verbesserung der Definitionen von User Agents und Ursprungsservern

A.2.2. Message Syntax and Routing (Nachrichtensyntax und Routing)​

  • Klarstellung des Nachrichtenframings
  • Klarstellung der Interaktion zwischen Transfer-Encoding und Content-Length
  • Detaillierte Beschreibung der Chunked-Übertragungskodierung

A.2.3. Connection Management (Verbindungsmanagement)​

  • Klarstellung des Verhaltens persistenter Verbindungen
  • Dokumentation der Einschränkungen des Pipelining
  • Detaillierte Beschreibung der Verbindungswiederverwendung und -schließung

A.2.4. Security Considerations (Sicherheitsbetrachtungen)​

  • Dokumentation von Request-Smuggling-Angriffen
  • Dokumentation von Response-Splitting-Angriffen
  • Hinzufügung von Sicherheitshinweisen zur Protokollelementlänge