Comment distribuer des échanges HTTP signés (SXG) à l'aide de nginx

Comment obtenir et diffuser des fichiers SXG à l'aide de nginx, et les défis liés au préchargement des sous-ressources.

Hiroki Kumazaki

En tant que distributeur de Signed HTTP Exchanges (SXG), vous pouvez envoyer des fichiers SXG au nom des créateurs de contenu d'origine. Les navigateurs Web compatibles avec les fichiers SXG les affichent comme s'ils avaient été diffusés par les créateurs de contenu d'origine. Vous pouvez ainsi implémenter le préchargement intersites sans porter atteinte à la confidentialité. Ce guide vous explique comment distribuer correctement des SXG.

Compatibilité entre les navigateurs

Chrome est actuellement le seul navigateur compatible avec les échanges signés. Pour en savoir plus, consultez la section "Consensus et normalisation" de Échanges HTTP signés par l'origine.

Obtenir des fichiers SXG

Dans l'en-tête de requête Accept, indiquez que vous souhaitez que le serveur renvoie un fichier SXG avec la requête:

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

Ce guide suppose que vous placez vos fichiers SXG dans /var/www/sxg.

Diffuser un fichier SXG simple

Joignez les en-têtes suivants pour distribuer un seul fichier SXG:

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

Configurez 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;
    }
    ...

Chargez la nouvelle configuration dans nginx:

sudo systemctl restart nginx.service

nginx commencera à diffuser les fichiers SXG. Lorsque Chrome accède à votre serveur, l'adresse de l'éditeur du contenu d'origine s'affiche dans la barre.

Précharger des sous-ressources

La plupart des pages Web se composent de plusieurs sous-ressources, telles que des fichiers CSS, JavaScript, des polices et des images. Le contenu d'un SXG ne peut pas être modifié sans la clé privée de son créateur. Cela entraîne des problèmes lorsque le navigateur tente de résoudre les sous-ressources.

Par exemple, supposons que index.html.sxg de https://website.test/index.html ait un lien vers https://website.test/app.js. Lorsque le navigateur d'un utilisateur reçoit le fichier SXG de https://distributor.test/example.com/index.html.sxg, il trouve le lien vers https://website.test/app.js. Le navigateur peut extraire https://website.test/app.js directement lors de l'accès réel, mais cela ne doit pas être fait lors de la phase de préchargement pour préserver la confidentialité. Si la ressource a été récupérée pendant la phase de préchargement, le créateur de contenu (website.test) peut détecter quel distributeur de contenu (distributor.test) demande la ressource.

Si le distributeur souhaite diffuser des app.js.sxg à partir de son propre service et tente de modifier https://website.test/app.js pour qu'il corresponde à la version du distributeur de cette sous-ressource (par exemple, https://distributor.test/website.test/app.js.sxg), cela entraînera une incohérence au niveau de la signature et l'échange signé ne sera pas valide.

Pour résoudre ce problème, une fonctionnalité expérimentale de préchargement des sous-ressources SXG est désormais disponible dans Chrome. Vous pouvez l'activer à l'adresse about://flags/#enable-sxg-subresource-prefetching. Pour utiliser le préchargement des sous-ressources, les conditions suivantes doivent être remplies:

• L'éditeur doit intégrer une entrée d'en-tête de réponse dans SXG, par exemple: link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=". Ce champ spécifie la sous-ressource qui peut être remplacée par le hachage d'intégrité spécifique du SXG.
• Le distributeur doit joindre un en-tête de réponse lorsqu'il diffuse le SXG, par exemple: link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js". Il spécifie le chemin d'accès de app.js et correspond à la sous-ressource.

La première est relativement facile, car nginx-sxg-module peut calculer des hachages d'intégrité et les intégrer dans les en-têtes de lien des réponses en amont. Mais la seconde est plus difficile, car le distributeur de contenu doit connaître les sous-ressources spécifiées dans l'échange signé.

S'il n'y a pas d'autres sous-ressources que https://website.test/app.js, il vous suffit d'ajouter ce qui suit dans votre configuration nginx:

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

Toutefois, de tels cas sont rares, car les sites Web standards contiennent de nombreuses sous-ressources. De plus, le distributeur doit joindre l'en-tête de lien d'ancrage approprié lorsqu'il diffuse un fichier SXG. Il n'existe actuellement aucun moyen simple de résoudre ce problème. Nous vous communiquerons prochainement plus d'informations à ce sujet.

Envoyer des commentaires

Les ingénieurs Chromium sont ravis de recevoir vos commentaires sur la distribution de SXG à l'adresse webpackage-dev@chromium.org. Vous pouvez également participer à la discussion sur les spécifications ou signaler un bug à l'équipe. Vos commentaires nous aideront grandement à standardiser le processus et à résoudre les problèmes d'implémentation. Merci !