So verteilen Sie Signed HTTP Exchanges (SXG) mit nginx

Informationen zum Abrufen und Bereitstellen von SXG-Dateien mit nginx und zu den Herausforderungen beim Vorabruf von Unterressourcen.

Hiroki Kumazaki

Als Signed HTTP Exchange (SXG)-Händler kannst du SXG-Dateien im Namen der ursprünglichen Ersteller von Inhalten übermitteln. In Webbrowsern, die SXG unterstützen, werden SXG-Dateien so angezeigt, als wären sie von den ursprünglichen Creatorn stammend. So können Sie das websiteübergreifende Vorabladen implementieren, ohne den Datenschutz zu verletzen. In diesem Leitfaden erfährst du, wie du SXG richtig verbreiten kannst.

Browserübergreifende Unterstützung

Chrome ist derzeit der einzige Browser, der SXG unterstützt. Konsens ansehen und Aktuelle Informationen finden Sie im Abschnitt zur Standardisierung von vom Ursprung signierte HTTP-Austausche.

SXG-Dateien abrufen

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

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

In diesem Leitfaden wird davon ausgegangen, dass du deine SXG-Dateien im Verzeichnis /var/www/sxg abspeicherst.

Einfache SXG-Datei bereitstellen

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

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

Über nginx werden SXG-Dateien bereitgestellt. Wenn Chrome auf deinen Server zugreift, wird die Adresse des ursprünglichen Inhalts-Publishers in der Leiste angezeigt.

Unterressourcen vorabrufen

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

Beispiel: index.html.sxg von https://website.test/index.html hat 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, wird der Link zu https://website.test/app.js gefunden. Der Browser kann https://website.test/app.js direkt beim tatsächlichen Zugriff abrufen. Aus Datenschutzgründen sollte dies jedoch nicht in der Vorladephase erfolgen. Wenn die Ressource während der Vorabladephase abgerufen wurde, könnte der Ersteller des Inhalts (website.test) erkennen, welcher Inhaltsvertreiber (distributor.test) die Ressource anfordert.

Wenn der Distributor app.js.sxg über seinen eigenen Dienst bereitstellen möchte und versucht, https://website.test/app.js in die Version dieser Unterressource des Distributors (z. B. https://distributor.test/website.test/app.js.sxg) zu ändern, führt dies zu einer nicht übereinstimmenden Signatur und macht die SXG ungültig.

Um dieses Problem zu lösen, gibt es jetzt in Chrome eine experimentelle Funktion zum Vorabruf von SXG-Unterressourcen. Du kannst es unter about://flags/#enable-sxg-subresource-prefetching aktivieren. Wenn Sie den Vorabruf von Unterressourcen verwenden möchten, müssen die folgenden Bedingungen erfüllt sein:

• Der Verlag oder Webpublisher muss einen Antwortheadereintrag 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=". Gibt die Unterressource an, 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, weil nginx-sxg-module Integritäts-Hashes berechnen und in Linkheadern aus Upstream-Antworten einbetten kann. Die zweite ist jedoch schwieriger, da der Inhaltsvertrieb die angegebenen Unterressourcen in der SXG kennen muss.

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

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

Solche Fälle sind jedoch selten, da typische Websites aus vielen Unterressourcen bestehen. Außerdem muss der Händler beim Bereitstellen einer SXG-Datei den richtigen Ankerlink-Header anhängen. Derzeit gibt es keine einfache Möglichkeit, dieses Problem zu beheben, also halten Sie Ausschau nach Updates!

Feedback geben

Chromium-Entwickler freuen sich auf dein Feedback zur Bereitstellung von SXG unter [e-mail]. Sie können sich auch an der Diskussion zu Spezifikationen beteiligen oder dem Team einen Fehler melden. Ihr Feedback hilft uns bei der Standardisierung und bei Problemen mit der Implementierung. Vielen Dank!