Como distribuir Signed HTTP Exchanges (SXG) usando nginx

Como receber e disponibilizar arquivos SXG usando o nginx e os desafios da pré-busca de sub-recursos.

Hiroki Kumazaki

Como distribuidor de Signed HTTP Exchanges (SXG), você pode enviar arquivos SXG em nome dos criadores do conteúdo original. Os navegadores da Web compatíveis com SXG exibirão esses arquivos SXG como se tivessem sido enviados pelos criadores do conteúdo original. Isso permite implementar o pré-carregamento entre sites sem violar a privacidade. Este guia mostra como distribuir SXG corretamente.

Suporte a vários navegadores

Atualmente, o Chrome é o único navegador que oferece suporte a SXG. Veja o consenso e Seção de padronização de Trocas HTTP assinadas com a origem para informações mais atualizadas.

Extrair arquivos SXG

Especifique no cabeçalho da solicitação Accept que você quer que o servidor retorne um arquivo SXG com a solicitação:

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

Este guia pressupõe que você coloque os arquivos SXG em /var/www/sxg.

Disponibilizar um arquivo SXG simples

Anexe os seguintes cabeçalhos para distribuir um único arquivo SXG:

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

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

Carregue a nova configuração em nginx:

sudo systemctl restart nginx.service

nginx vai começar a veicular arquivos SXG. Quando o Chrome acessar seu servidor, o endereço do editor de conteúdo original aparecerá na barra.

Sub-recursos de pré-busca

A maioria das páginas da Web consiste em vários sub-recursos, como CSS, JavaScript, fontes e imagens. O conteúdo das SXG não pode ser alterado sem a chave privada do criador do conteúdo. Isso causa problemas quando o navegador tenta resolver sub-recursos.

Por exemplo, suponha que index.html.sxg de https://website.test/index.html tenha um link para https://website.test/app.js. Quando o navegador de um usuário receber o arquivo SXG de https://distributor.test/example.com/index.html.sxg, ele encontrará o link para https://website.test/app.js. O navegador pode buscar https://website.test/app.js diretamente no acesso real, mas isso não deve ser feito na fase de pré-carregamento para preservar a privacidade. Se o recurso foi buscado durante a fase de pré-carregamento, o criador de conteúdo (website.test) pode detectar qual distribuidor de conteúdo (distributor.test) está solicitando o recurso.

Se o distribuidor quiser disponibilizar app.js.sxg do próprio serviço e tentar modificar https://website.test/app.js para ser a versão desse sub-recurso (como https://distributor.test/website.test/app.js.sxg), isso vai causar uma incompatibilidade de assinatura e invalidar as SXG.

Para resolver esse problema, já existe um recurso experimental de pré-busca de sub-recursos SXG no Chrome. Faça a ativação em: about://flags/#enable-sxg-subresource-prefetching. Para usar a pré-busca de sub-recursos, as seguintes condições precisam ser atendidas:

• O editor precisa incorporar uma entrada de cabeçalho de resposta em 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=". Isso especifica o sub-recurso que pode ser substituído pelo hash de integridade específico da SXG.
• O distribuidor precisa anexar um cabeçalho de resposta ao veicular as SXGs, como: link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js". Isso especifica o caminho de app.js e corresponde ao sub-recurso.

O primeiro é relativamente fácil, porque o nginx-sxg-module pode calcular hashes de integridade e incorporá-los a cabeçalhos de links de respostas upstream. Mas o segundo é mais difícil porque o distribuidor de conteúdo precisa estar ciente dos sub-recursos especificados nas SXG.

Se não houver sub-recursos além de https://website.test/app.js, anexe tudo na configuração do nginx:

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

Mas esses casos são raros, porque os sites típicos consistem em muitos sub-recursos. Além disso, o distribuidor deve anexar o cabeçalho do link âncora adequado ao exibir um arquivo SXG. Atualmente, não existe uma maneira fácil de resolver esse problema, portanto, fique atento às atualizações!

Enviar feedback

Os engenheiros do Chromium querem saber sua opinião sobre a distribuição de SXG pelo e-mail webpackage-dev@chromium.org. Você também pode participar da discussão sobre especificações ou informar um bug para a equipe. Seu feedback ajudará muito no processo de padronização e também a resolver problemas de implementação. Valeu!