Anhang B. Betriebliche Überlegungen für Server (Operational Considerations for Servers)

Der ORIGIN-Frame ermöglicht es einem Server, anzugeben, für welche Ursprünge eine gegebene Verbindung verwendet werden sollte. Die Menge der mit diesem Mechanismus beworbenen Ursprünge unterliegt der Kontrolle des Servers; Server sind nicht verpflichtet, ihn zu verwenden oder alle Ursprünge zu bewerben, für die sie möglicherweise eine Anfrage beantworten können.

Beispielsweise kann er verwendet werden, um den Client darüber zu informieren, dass die Verbindung nur für den SNI-basierten Ursprung verwendet werden soll, indem ein leerer ORIGIN-Frame gesendet wird. Oder es kann eine größere Anzahl von Ursprüngen angegeben werden, indem eine Nutzlast eingefügt wird.

Im Allgemeinen ist es am nützlichsten, diese Informationen zu senden, bevor ein Teil einer Antwort gesendet wird, der eine neue Verbindung initiieren könnte; zum Beispiel "Link"-Antwort-Header-Felder [RFC8288] oder Links im Antworttext.

Daher sollte der ORIGIN-Frame so schnell wie möglich auf einer Verbindung gesendet werden, idealerweise vor allen HEADERS- oder PUSH_PROMISE-Frames.

Wenn es jedoch wünschenswert ist, eine große Anzahl von Ursprüngen mit einer Verbindung zu verknüpfen, könnte dies aufgrund ihrer Größe zu einer vom Endbenutzer wahrgenommenen Latenz führen. Infolgedessen könnte es notwendig sein, einen "Kern"-Satz von Ursprüngen auszuwählen, der anfänglich gesendet wird, und den Satz von Ursprüngen, für den die Verbindung verwendet wird, später mit nachfolgenden ORIGIN-Frames zu erweitern (z. B. wenn die Verbindung im Leerlauf ist).

Dennoch werden Absender ermutigt, so viele Ursprünge wie praktisch möglich in einen einzigen ORIGIN-Frame aufzunehmen; Clients müssen Entscheidungen über das Erstellen von Verbindungen spontan treffen, und wenn das Origin-Set auf viele Frames aufgeteilt ist, könnte ihr Verhalten suboptimal sein.

Absender beachten bitte, dass gemäß Abschnitt 4, Schritt 5 von [RFC6454] die Werte in einem ORIGIN-Header vor der Serialisierung in Bezug auf Groß-/Kleinschreibung normalisiert werden müssen.

Schließlich müssen Server, die alternative Dienste [RFC7838] hosten, ihre Ursprünge beim Senden von ORIGIN explizit bewerben, da der Standardinhalt des Origin-Sets (gemäß Abschnitt 2.3) keine Ursprünge alternativer Dienste enthält, selbst wenn diese zuvor auf der Verbindung verwendet wurden.