Signed HTTP Exchange (ou "SXG") est un sous-ensemble de cette technologie émergente, Les packages Web, qui permettent aux éditeurs rendre leur contenu portable en toute sécurité, c'est-à-dire qu'ils pourront être redistribués par d'autres parties, tout en préservant l'intégrité et l'attribution du contenu. Portables présente de nombreux avantages : diffusion plus rapide, faciliter le partage de contenu entre les utilisateurs et simplifier les expériences hors connexion.
Comment fonctionnent les échanges HTTP signés ? Cette technologie permet à un éditeur signer un seul échange HTTP (c'est-à-dire une paire requête/réponse), de sorte que l'échange signé puisse être provenant de n'importe quel serveur de mise en cache. Lorsque le navigateur charge cet échange signé, l'URL de l'éditeur s'affiche en toute sécurité dans la barre d'adresse, car la signature dans l'échange constitue une preuve suffisante que le contenu provient à l'origine de la l'origine de l'éditeur.
Cela permet de dissocier l'origine du contenu de celui qui le distribue. Votre contenu peuvent être publiés sur le Web, sans dépendre d'un serveur, d'une connexion, ou d'un service d'hébergement. Nous sommes ravis des utilisations possibles de l'échange signé, par exemple:
Préchargement respectueux de la confidentialité:lors du préchargement des ressources (par exemple, par lien rel=prefetch) pour une navigation ultérieure peut rendre la navigation beaucoup plus rapide, présente également des inconvénients en matière de confidentialité. Par exemple, le préchargement des ressources les navigations multi-origines indiqueront au site de destination que l'utilisateur est potentiellement intéressé par une information, même si l'utilisateur n'ont finalement pas consulté le site. D'autre part, les échanges signés précharger les ressources multi-origines depuis un cache rapide sans jamais atteindre vers le site de destination. Ainsi, nous ne communiquons l'intérêt des utilisateurs lors de la navigation. Nous pensons que cela peut être utile pour les sites dont l'objectif est de rediriger les utilisateurs vers d'autres sites Web. En particulier, Google prévoit de l'utiliser sur les pages de résultats de recherche Google améliorer les URL AMP et accélérer les clics dans les résultats de recherche.
Avantages d'un CDN sans céder le contrôle de la clé privée de votre certificat: Un contenu qui est devenu soudainement populaire (par exemple, un lien depuis la première page de reddit.com) surchargent souvent le site. où le contenu est diffusé. Si le site est de taille relativement petite, il a tendance ralentir ou même devenir temporairement indisponibles. Cette situation peut se produire à éviter si le contenu est partagé à l'aide de serveurs de cache rapides et puissants, et d'échanges signés rend cela possible sans partager vos clés TLS.
Essayer les échanges signés
Les échanges signés sont disponibles dans Chrome 73 et les versions ultérieures. en tant qu'évaluation d'origine.
Créer un échange signé
Afin de créer des SXG pour votre origine (en tant qu'éditeur), vous devez disposer d'un clé de certificat pour signer la signature et le certificat doit avoir une adresse e-mail "CanSignHttpExchanges" doit être traité comme un échange signé. Depuis novembre 2018, DigiCert est la seule autorité de certification qui prend en charge cette extension, et vous pouvez demander qui fonctionne pour les échanges signés cette page.
Une fois que vous avez obtenu un certificat pour un échange signé, vous pouvez créer vos propres échanges en utilisant le outils générateurs de références publiées sur GitHub.
Vous pouvez également consulter les fichiers d'exemple SXG Dépôt de code de Chrome (par exemple, celui-ci est le plus simple créé pour un simple fichier texte). Notez qu'ils sont générés principalement pour des tests en local. Ne vous attendez pas à qu’ils ont des certificats et des horodatages valides dans la signature.
Tester la fonctionnalité en local
Pour créer des échanges signés à des fins de test, vous pouvez créer
Un certificat autosigné
et activez chrome://flags/#allow-sxg-certs-without-extension pour que votre
Chrome traite les échanges signés avec le certificat sans l'extension spéciale.
Un code de ce type devrait fonctionner si votre serveur, votre certificat et vos échanges signés sont correctement configurés:
<!-- prefetch the sample.sxg -->
<link rel="prefetch" href="https://your-site.com/sample.sxg" />
<!-- clicking the link below should make Chrome navigate to the inner
response of sample.sxg (and the prefetched SXG is used) -->
<a href="https://your-site.com/sample.sxg">Sample</a>
Notez que l'échange signé n'est compatible qu'avec la balise d'ancrage (<a>) et link rel=prefetch
dans Chrome 73 et versions ultérieures. Notez également que la validité de la signature est limitée à sept
jours par spécification, de sorte que vos contenus signés expirent assez rapidement.
Fournir des commentaires
Nous aimerions connaître votre avis sur cette expérience à l'adresse webpackage-dev@chromium.org. Vous pouvez et participez à la discussion sur les spécifications. ou signaler un bug Chrome à l'équipe. Vos commentaires nous aideront grandement dans le processus de normalisation. mais aussi à résoudre les problèmes de mise en œuvre.