2. Der ORIGIN HTTP/2 Frame (The ORIGIN HTTP/2 Frame)

Dieses Dokument definiert einen neuen HTTP/2-Frame-Typ ([RFC7540], Abschnitt 4) namens ORIGIN, der es einem Server ermöglicht, anzugeben, welche(n) Ursprung/Ursprünge [RFC6454] der Server möchte, dass der Client als Mitglieder des Origin-Sets (Abschnitt 2.3) für die Verbindung betrachtet, in der er auftritt.

2.1. Syntax

Der ORIGIN-Frame-Typ ist 0xc (dezimal 12) und enthält null oder mehr Instanzen des Origin-Entry-Feldes.

+-------------------------------+-------------------------------+
|         Origin-Entry (*)                                    ...
+-------------------------------+-------------------------------+

Ein Origin-Entry ist eine längenbegrenzte Zeichenfolge:

+-------------------------------+-------------------------------+
|         Origin-Len (16)       | ASCII-Origin?               ...
+-------------------------------+-------------------------------+

Konkret:

Origin-Len: Eine vorzeichenlose 16-Bit-Ganzzahl, die die Länge des ASCII-Origin-Feldes in Oktetten angibt.

Origin: Eine OPTIONALE Zeichenfolge, die die ASCII-Serialisierung eines Ursprungs ([RFC6454], Abschnitt 6.2) enthält, für den der Absender behauptet, dass diese Verbindung autoritativ ist oder sein könnte.

Der ORIGIN-Frame definiert keine Flags. Zukünftige Aktualisierungen dieser Spezifikation KÖNNEN jedoch Flags definieren. Siehe Abschnitt 2.2.

2.2. Verarbeitung von ORIGIN-Frames

Der ORIGIN-Frame ist eine nicht kritische Erweiterung von HTTP/2. Endpunkte, die diesen Frame nicht unterstützen, können ihn beim Empfang sicher ignorieren.

Wenn er von einem implementierenden Client empfangen wird, wird er verwendet, um das Origin-Set (siehe Abschnitt 2.3) zu initialisieren und zu manipulieren, wodurch geändert wird, wie der Client die Autorität für Ursprungsserver festlegt (siehe Abschnitt 2.4).

Der ORIGIN-Frame MUSS auf Stream 0 gesendet werden; ein ORIGIN-Frame auf einem anderen Stream ist ungültig und MUSS ignoriert werden.

Ebenso ist der ORIGIN-Frame nur auf Verbindungen mit dem Protokollbezeichner "h2" gültig oder wenn er durch die Protokolldefinition ausdrücklich benannt wurde; er MUSS ignoriert werden, wenn er auf einer Verbindung mit dem Protokollbezeichner "h2c" empfangen wird.

Diese Spezifikation definiert keine Flags für den ORIGIN-Frame, aber zukünftige Aktualisierungen dieser Spezifikation (durch IETF-Konsens) könnten sie verwenden, um ihre Semantik zu ändern. Die ersten vier Flags (0x1, 0x2, 0x4 und 0x8) sind für rückwärtsinkompatible Änderungen reserviert; wenn also eines von ihnen gesetzt ist, MUSS der ORIGIN-Frame, der sie enthält, von Clients, die dieser Spezifikation entsprechen, ignoriert werden, es sei denn, die Semantik des Flags wird verstanden. Die verbleibenden Flags sind für rückwärtskompatible Änderungen reserviert und beeinflussen die Verarbeitung durch Clients, die dieser Spezifikation entsprechen, nicht.

Der ORIGIN-Frame beschreibt eine Eigenschaft der Verbindung und wird daher Hop-by-Hop verarbeitet. Ein Vermittler DARF ORIGIN-Frames NICHT weiterleiten. Clients, die für die Verwendung eines Proxys konfiguriert sind, MÜSSEN alle von diesem empfangenen ORIGIN-Frames ignorieren.

Jedes ASCII-Origin-Feld in der Nutzlast des Frames MUSS als ASCII-Serialisierung eines Ursprungs ([RFC6454], Abschnitt 6.2) geparst werden. Wenn das Parsen fehlschlägt, MUSS das Feld ignoriert werden.

Beachten Sie, dass der ORIGIN-Frame keine Wildcard-Namen (z. B. "*.example.com") im Origin-Entry unterstützt. Infolgedessen deaktiviert das Senden von ORIGIN bei Verwendung eines Wildcard-Zertifikats effektiv alle Ursprünge, die nicht explizit im/in den ORIGIN-Frame(s) aufgeführt sind (wenn der Client ORIGIN versteht).

Siehe Anhang A für einen illustrativen Algorithmus zur Verarbeitung von ORIGIN-Frames.

2.3. Das Origin-Set

Die Menge der Ursprünge (gemäß [RFC6454]), für die eine gegebene Verbindung verwendet werden könnte, wird in dieser Spezifikation als Origin-Set bezeichnet.

Standardmäßig ist das Origin-Set für eine Verbindung nicht initialisiert. Ein nicht initialisiertes Origin-Set bedeutet, dass Clients die Coalescing-Regeln aus Abschnitt 9.1.1 von [RFC7540] anwenden.

Wenn ein ORIGIN-Frame zum ersten Mal empfangen und von einem Client erfolgreich verarbeitet wird, ist das Origin-Set der Verbindung so definiert, dass es einen anfänglichen Ursprung enthält. Der anfängliche Ursprung setzt sich zusammen aus:

• Schema: "https"
• Host: der im Server Name Indication (SNI) ([RFC6066], Abschnitt 3) gesendete Wert, in Kleinbuchstaben umgewandelt; wenn SNI nicht vorhanden ist, die Remote-Adresse der Verbindung (d. h. die IP-Adresse des Servers)
• Port: der Remote-Port der Verbindung (d. h. der Port des Servers)

Der Inhalt dieses ORIGIN-Frames (und nachfolgender) ermöglicht es dem Server, dem Origin-Set inkrementell neue Ursprünge hinzuzufügen, wie in Abschnitt 2.2 beschrieben.

Das Origin-Set wird auch durch den Antwortstatuscode 421 (Misdirected Request) beeinflusst, wie in [RFC7540], Abschnitt 9.1.2 definiert. Bei Erhalt einer Antwort mit diesem Statuscode MÜSSEN implementierende Clients die ASCII-Serialisierung des Ursprungs der entsprechenden Anfrage erstellen (gemäß [RFC6454], Abschnitt 6.2) und sie aus dem Origin-Set der Verbindung entfernen, falls vorhanden.

Hinweis: Beim Senden eines ORIGIN-Frames an eine Verbindung, die als alternativer Dienst [RFC7838] initialisiert ist, enthält das anfängliche Origin-Set (Abschnitt 2.3) einen Ursprung mit dem entsprechenden Schema und Hostnamen (da RFC 7838 spezifiziert, dass der Hostname des Ursprungs in SNI gesendet wird). Es ist jedoch möglich, dass der Port ein anderer ist als der des beabsichtigten Ursprungs, da das anfängliche Origin-Set unter Verwendung des tatsächlich verwendeten Ports berechnet wird, der für den alternativen Dienst unterschiedlich sein kann. In diesem Fall muss der beabsichtigte Ursprung explizit im ORIGIN-Frame gesendet werden.

Beispielsweise wird ein Client, der Anfragen für "https://example.com" stellt, zu einem alternativen Dienst unter ("h2", "x.example.net", "8443") geleitet. Wenn dieser alternative Dienst einen ORIGIN-Frame sendet, lautet der anfängliche Ursprung "https://example.com:8443". Der Client kann den alternativen Dienst nicht verwenden, um Anfragen für "https://example.com" zu stellen, es sei denn, dieser Ursprung ist explizit im ORIGIN-Frame enthalten.

2.4. Autorität, Push und Coalescing mit ORIGIN

Abschnitt 10.1 von [RFC7540] verwendet sowohl DNS als auch das präsentierte Transport Layer Security (TLS)-Zertifikat, um den/die Ursprungsserver festzulegen, für den/die eine Verbindung autoritativ ist, genau wie HTTP/1.1 dies in [RFC7230] tut.

Darüber hinaus erlaubt Abschnitt 9.1.1 von [RFC7540] ausdrücklich, dass eine Verbindung für mehr als einen Ursprungsserver verwendet werden kann, wenn sie autoritativ ist. Dies beeinflusst, welche Antworten als autoritativ angesehen werden können, sowohl für direkte Antworten auf Anfragen als auch für Server-Push (siehe [RFC7540], Abschnitt 8.2.2). Indirekt beeinflusst es auch, welche Anfragen auf einer Verbindung gesendet werden, da Clients im Allgemeinen nur Anfragen auf Verbindungen senden, von denen sie glauben, dass sie für den betreffenden Ursprung autoritativ sind.

Sobald ein Origin-Set für eine Verbindung initialisiert wurde, verwenden Clients, die diese Spezifikation implementieren, es, um zu bestimmen, wofür die Verbindung autoritativ ist. Insbesondere DÜRFEN solche Clients eine Verbindung NICHT als autoritativ für einen Ursprung betrachten, der nicht im Origin-Set vorhanden ist, und sie SOLLTEN die Verbindung für alle Anfragen an Ursprünge im Origin-Set verwenden, für die die Verbindung autoritativ ist, es sei denn, es gibt betriebliche Gründe für das Öffnen einer neuen Verbindung.

Beachten Sie, dass der Server, damit eine Verbindung als autoritativ für einen bestimmten Ursprung angesehen werden kann, sich immer noch mit einem Zertifikat authentifizieren muss, das geeignete Prüfungen besteht; siehe Abschnitt 9.1.1 von [RFC7540] für weitere Informationen. Dies beinhaltet die Überprüfung, ob der Host mit einem "dNSName"-Wert aus dem Feld "subjectAltName" des Zertifikats übereinstimmt (unter Verwendung der in [RFC2818] definierten Regeln; siehe auch [RFC5280], Abschnitt 4.2.1.6).

Zusätzlich KÖNNEN Clients vermeiden, DNS zu konsultieren, um die Autorität der Verbindung für neue Anfragen an Ursprünge im Origin-Set festzulegen; diejenigen, die dies tun, sind jedoch neuen Risiken ausgesetzt, wie in Abschnitt 4 erläutert.

Da ORIGIN die Menge der Ursprünge, für die eine Verbindung verwendet wird, im Laufe der Zeit ändern kann, ist es möglich, dass ein Client jederzeit mehr als eine praktikable Verbindung zu einem Ursprung offen hat. Wenn dies auftritt, SOLLTEN Clients KEINE neuen Anfragen auf einer Verbindung ausgeben, deren Origin-Set eine echte Teilmenge des Origin-Sets einer anderen Verbindung ist, und sie SOLLTEN sie schließen, sobald alle ausstehenden Anfragen erfüllt sind.

Das Origin-Set bleibt von Ankündigungen alternativer Dienste [RFC7838] durch den Server unberührt. Die Werbung für einen alternativen Dienst hat keinen Einfluss darauf, ob ein Server autoritativ ist.