Informationen zum Abrufen und Bereitstellen von SXG-Dateien mit nginx sowie zu den Herausforderungen beim Vorabladen von Unterressourcen.
Als Signed HTTP Exchanges (SXG)-Distributor kannst du SXG-Dateien im Namen der ursprünglichen Ersteller von Inhalten bereitstellen. In Webbrowsern, die SXG unterstützen, werden solche SXG-Dateien so angezeigt, als wären sie von den ursprünglichen Creatorn gesendet worden. So können Sie das standortübergreifende Vorabladen implementieren, ohne den Datenschutz zu verletzen. In dieser Anleitung erfahren Sie, wie Sie SXG-Dateien richtig verteilen.
Browserübergreifende Unterstützung
Chrome ist derzeit der einzige Browser, der SXG unterstützt. Aktuelle Informationen finden Sie im Abschnitt „Konsens und Standardisierung“ des Artikels Von Ursprungsservern signierte HTTP-Austausche.
SXG-Dateien abrufen
Gib in deinem Accept
-Anfrageheader an, dass der Server zusammen mit der Anfrage eine SXG-Datei zurückgeben soll:
Accept: application/signed-exchange;v=b3,*/*;q=0.8
In dieser Anleitung wird davon ausgegangen, dass Sie Ihre SXG-Dateien in /var/www/sxg
ablegen.
Eine einfache SXG-Datei bereitstellen
Hängen Sie die folgenden Header an, um eine einzelne SXG-Datei bereitzustellen:
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
beginnt dann mit der Auslieferung von SXG-Dateien.
Wenn Chrome auf deinen Server zugreift, wird in der Leiste die Adresse des ursprünglichen Inhaltsanbieters angezeigt.
Untergeordnete Ressourcen im Prefetch
Die meisten Webseiten bestehen aus mehreren Unterressourcen wie CSS, JavaScript, Schriftarten und Bildern. Der Inhalt von SXG kann nicht ohne den privaten Schlüssel des Erstellers geändert werden. Das führt zu Problemen, wenn der Browser versucht, untergeordnete Ressourcen aufzulösen.
Angenommen, 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, dies sollte jedoch nicht in der Preloading-Phase erfolgen, um die Privatsphäre zu schützen.
Wenn die Ressource während der Preloading-Phase abgerufen wurde, kann der Creator (website.test
) erkennen, welcher Inhaltsdistributor (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 der Unterressource des Distributors (z. B. https://distributor.test/website.test/app.js.sxg
) zu ändern, führt dies zu einer Abweichung der Signatur und macht die SXG ungültig.
Um dieses Problem zu lösen, gibt es in Chrome jetzt eine experimentelle Funktion zum Vorabladen von SXG-Unterressourcen.
Sie können sie unter about://flags/#enable-sxg-subresource-prefetching
aktivieren.
Damit das Vorabladen von Unterressourcen verwendet werden kann, 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="
. Hier wird die Unterressource angegeben, die durch den spezifischen Integritäts-Hash der 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"
. Hiermit wird der Pfad vonapp.js
angegeben und der untergeordneten Ressource zugeordnet.
Die erste ist relativ einfach, da nginx-sxg-module
Integritätshasches berechnen und in Link-Header aus Upstream-Antworten einbetten kann. Letzteres ist jedoch schwieriger, da der Inhaltsanbieter über die angegebenen Unterressourcen in der SXG Bescheid wissen muss.
Wenn es keine anderen untergeordneten Ressourcen als https://website.test/app.js
gibt, müssen Sie in Ihrer nginx-Konfiguration nur 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 Distributor beim Ausliefern einer SXG-Datei den richtigen Ankerlink-Header anhängen. Derzeit gibt es keine einfache Möglichkeit, dieses Problem zu beheben. Wir halten dich aber auf dem Laufenden.
Feedback geben
Die Chromium-Entwickler freuen sich über Ihr Feedback zum Verteilen von SXG unter webpackage-dev@chromium.org. Sie können auch an der Diskussion zur Spezifikation teilnehmen oder dem Team einen Fehler melden. Ihr Feedback trägt wesentlich zum Standardisierungsprozess bei und hilft uns auch, Implementierungsprobleme zu beheben. Vielen Dank!