So verteilen Sie Signed HTTP Exchanges (SXG) mit nginx

Abrufen und Bereitstellen von SXG-Dateien mit nginx und Herausforderungen beim Vorabruf von Unterressourcen

Hiroki Kumazaki

Als Distributor von Signed HTTP Exchanges (SXG) kannst du SXG-Dateien im Namen der Ersteller der Inhalte bereitstellen. In Webbrowsern, die SXG unterstützen, werden solche SXG-Dateien so angezeigt, als wären sie vom ursprünglichen Ersteller der Inhalte bereitgestellt worden. So kannst du websiteübergreifendes Vorabladen ohne Verletzung des Datenschutzes implementieren. In diesem Leitfaden erfährst du, wie du SXG richtig verteilen kannst.

Browserübergreifende Unterstützung

Chrome ist derzeit der einzige Browser, der SXG unterstützt. Aktuelle Informationen finden Sie im Abschnitt „Consensus & Standardization“ (Konsens und Standardisierung) des Artikels Origin-Signed HTTP Exchanges.

SXG-Dateien herunterladen

Geben Sie im Accept-Anfrageheader an, dass der Server eine SXG-Datei zusammen mit der Anfrage zurückgeben soll:

Accept: application/signed-exchange;v=b3,*/*;q=0.8

In dieser Anleitung wird davon ausgegangen, dass du deine SXG-Dateien in /var/www/sxg speicherst.

Einfache SXG-Datei bereitstellen

Um eine einzelne SXG-Datei zu verteilen, hängen Sie die folgenden Header an:

Content-Type: application/signed-exchange;v=v3
X-Content-Type-Options: nosniff

Konfigurieren Sie nginx:

http {
    ...
    types {
        application/signed-exchange;v=b3  sxg;
    }
    add_header X-Content-Type-Options nosniff;

    location / {
        more_set_headers "Content-Type: application/signed-exchange;v=b3";
        alias /var/www/sxg/;
        try_files $uri.sxg $uri =404;
        autoindex off;
    }
    ...

Laden Sie die neue Konfiguration in nginx:

sudo systemctl restart nginx.service

nginx stellt nun SXG-Dateien bereit. Wenn Chrome auf deinen Server zugreift, wird die Adresse des ursprünglichen Inhalts-Publishers in der Leiste angezeigt.

Prefetch-Unterressourcen

Die meisten Webseiten bestehen aus mehreren Unterressourcen wie CSS, JavaScript, Schriftarten und Bildern. Die Inhalte von SXG können nur mit dem privaten Schlüssel des Creators geändert werden. Dies führt zu Problemen, wenn der Browser versucht, Unterressourcen aufzulösen.

Angenommen, index.html.sxg von https://website.test/index.html enthält einen Link zu https://website.test/app.js. Wenn der Browser eines Nutzers die SXG-Datei von https://distributor.test/example.com/index.html.sxg empfängt, findet er den Link zu https://website.test/app.js. Der Browser kann https://website.test/app.js direkt beim eigentlichen Zugriff abrufen. Aus Datenschutzgründen sollte dies jedoch nicht in der Vorabladephase erfolgen. Wenn die Ressource während der Vorabladephase abgerufen wurde, könnte der Ersteller von Inhalten (website.test) erkennen, welcher Content Distributor (distributor.test) die Ressource anfordert.

Wenn der Händler app.js.sxg über seinen eigenen Dienst bereitstellen möchte und versucht, https://website.test/app.js in die Version der Unterressource des Händlers (z. B. https://distributor.test/website.test/app.js.sxg) zu ändern, führt dies zu einer abweichenden Signatur und dazu, dass der SXG ungültig wird.

Um dieses Problem zu lösen, gibt es in Chrome jetzt eine experimentelle Funktion für den Vorabruf von SXG-Unterressourcen. Sie können sie hier aktivieren: about://flags/#enable-sxg-subresource-prefetching. Damit Sie den Vorabruf von Unterressourcen verwenden können, müssen die folgenden Bedingungen erfüllt sein:

• Der Verlag oder Webpublisher muss einen Antwortheader in SXG einbetten, z. B. link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=". Damit wird die Unterressource angegeben, die durch den spezifischen Integritäts-Hash des SXG ersetzt werden kann.
• Der Distributor muss beim Bereitstellen des SXG einen Antwortheader anhängen, z. B. link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js". Gibt den Pfad von app.js an und entspricht der Unterressource.

Die erste ist relativ einfach, da mit nginx-sxg-module Integritäts-Hashes berechnet und in Linkheadern aus vorgelagerten Antworten eingebettet werden können. Die zweite ist allerdings schwieriger, weil der Inhaltsvertrieb die angegebenen Unterressourcen im SXG kennen muss.

Wenn außer https://website.test/app.js keine Unterressourcen vorhanden sind, müssen Sie nur Folgendes in Ihre nginx-Konfiguration anhängen:

add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...

Solche Fälle kommen jedoch selten vor, da typische Websites aus vielen Unterressourcen bestehen. Außerdem muss der Händler bei der Bereitstellung einer SXG-Datei den richtigen Ankerlink-Header anhängen. Derzeit gibt es keine einfache Möglichkeit, dieses Problem zu beheben. Wir halten Sie auf dem Laufenden!

Feedback geben

Die Chromium-Entwickler freuen sich auf euer Feedback zur Verbreitung von SXG unter webpackage-dev@chromium.org. Außerdem kannst du an der Diskussion zu den Spezifikationen teilnehmen oder dem Team einen Fehler melden. Ihr Feedback hilft uns sehr, den Standardisierungsprozess zu optimieren und Probleme bei der Implementierung zu lösen. Vielen Dank!