Cómo obtener y entregar archivos SXG con nginx y los desafíos de la carga previa de subrecursos
Como distribuidor de intercambios HTTP firmados (SXG), puedes enviar archivos SXG en nombre de los creadores de contenido originales. Los navegadores web compatibles con SXG mostrarán los archivos SXG como si los hubieran enviado los creadores de contenido original. Esto te permite implementar la precarga entre sitios sin infringir la privacidad. En esta guía, se muestra cómo distribuir SXG correctamente.
Compatibilidad con varios navegadores
Actualmente, Chrome es el único navegador compatible con SXG. Consulta el consenso y Sección de estandarización de Intercambios de HTTP firmados por el origen para obtener información más actualizada.
Obtener archivos SXG
En el encabezado de la solicitud Accept
, especifica que deseas que el servidor muestre un archivo SXG junto con la solicitud:
Accept: application/signed-exchange;v=b3,*/*;q=0.8
En esta guía, se supone que colocas tus archivos SXG en /var/www/sxg
.
Entrega un archivo SXG simple
Adjunta los siguientes encabezados para distribuir un solo archivo SXG:
Content-Type: application/signed-exchange;v=v3
X-Content-Type-Options: nosniff
Configura 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;
}
...
Carga la configuración nueva en nginx
:
sudo systemctl restart nginx.service
nginx
comenzará a entregar archivos SXG.
Cuando Chrome acceda a tu servidor, la dirección del editor de contenido original aparecerá en la barra.
Subrecursos de carga previa
La mayoría de las páginas web se componen de varios subrecursos, como CSS, JavaScript, imágenes y fuentes. El contenido de SXG no se puede cambiar sin la clave privada del creador del contenido. Esto genera problemas cuando el navegador intenta resolver subrecursos.
Por ejemplo, supongamos que index.html.sxg
de https://website.test/index.html
tiene un vínculo a https://website.test/app.js
. Cuando el navegador del usuario reciba el archivo SXG de https://distributor.test/example.com/index.html.sxg
, encontrará el vínculo a https://website.test/app.js
.
El navegador puede recuperar https://website.test/app.js
directamente durante el acceso real, pero no se debe realizar en la fase de precarga para preservar la privacidad.
Si el recurso se recuperó durante la fase de precarga, el creador de contenido (website.test
) podría detectar qué distribuidor (distributor.test
) solicita el recurso.
Si el distribuidor quiere publicar app.js.sxg
desde su propio servicio y trata de modificar https://website.test/app.js
para que sea la versión del distribuidor de ese subrecurso (como https://distributor.test/website.test/app.js.sxg
), se generará una discrepancia de firma y se invalidará el SXG.
Para resolver este problema, ahora en Chrome existe una función experimental de carga previa de subrecursos de SXG.
Puedes habilitarla en about://flags/#enable-sxg-subresource-prefetching
.
Para usar la carga previa de subrecursos, se deben cumplir las siguientes condiciones:
- El editor debe incorporar una entrada de encabezado de respuesta en SXG, como
link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk="
. Esto especifica el subrecurso que puede sustituirse por el hash de integridad específico de SXG. - El distribuidor debe adjuntar un encabezado de respuesta cuando publique la SXG, como
link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js"
. Esto especifica la ruta de acceso deapp.js
y corresponde al subrecurso.
La primera es relativamente fácil porque nginx-sxg-module
puede calcular hashes de integridad y, luego, incorporarlos en encabezados de vínculo desde respuestas ascendentes. Sin embargo, el segundo es más difícil porque el distribuidor de contenido debe conocer los subrecursos especificados en el SXG.
Si no hay subrecursos aparte de https://website.test/app.js
, todo lo que necesitas agregar en tu configuración de nginx es el siguiente:
add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...
Sin embargo, estos casos son poco frecuentes porque los sitios web típicos constan de una gran cantidad de subrecursos. Además, el distribuidor debe adjuntar el encabezado del vínculo de anclaje adecuado al publicar un archivo SXG. Actualmente, no hay una forma fácil de resolver este problema, así que no te pierdas las novedades.
Enviar comentarios
A los ingenieros de Chromium les interesa recibir tus comentarios sobre la distribución de SXG a la dirección webpackage-dev@chromium.org. También puedes unirte al debate sobre especificaciones o informar un error al equipo. Tus comentarios serán de gran ayuda con el proceso de estandarización y también abordarán los problemas de implementación. ¡Gracias!