Cómo distribuir intercambios HTTP firmados (SXG) con nginx

Cómo obtener y entregar archivos SXG con nginx y los desafíos de la carga previa de subrecursos

Hiroki Kumazaki

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 de app.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 [e-mail]. 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!