Resumo

  • RFC 9842 permite usar uma resposta HTTP como dicionário externo em solicitações futuras que atendam às regras de origem, URL, destino e validade.
  • A presença do dicionário, o hash anunciado, a escolha de Content-Encoding, a variante de cache e o sentido da resposta são evidências diferentes.

O ganho de compressão pode esconder uma diferença decisiva. Um cliente pode conservar bytes de uma resposta anterior e um servidor pode aproveitá-los para tornar a próxima transferência menor. Ainda assim, o cliente não possui a próxima resposta. Ele possui um insumo local que talvez seja utilizável em uma negociação específica.

Use-As-Dictionary inicia essa negociação. O servidor anuncia que uma resposta pode funcionar como dicionário para solicitações que cumpram o padrão match. O padrão é limitado à mesma origem; match-dest pode limitar destinos de Fetch; id e type descrevem condições adicionais. O id é opaco para o cliente e não pode servir ao servidor como garantia do conteúdo do dicionário. Um nome fornecido pelo servidor não é uma prova do que os bytes representam.

O cliente deve fazer sua própria verificação: o dicionário é fresco, ou seu uso obsoleto é permitido? A nova solicitação tem a mesma origem? O destino e o padrão coincidem? Se mais de um dicionário combina, há uma ordem de escolha. O resultado não é uma verdade ampla; é apenas a elegibilidade de um dicionário para ser anunciado numa requisição.

Quando escolhe oferecê-lo, o cliente envia um único hash SHA-256 em Available-Dictionary e pode incluir dcb ou dcz em Accept-Encoding. Isso não obriga o servidor a comprimir com aquele dicionário. O servidor conserva a escolha entre uma representação comum, outro algoritmo ou uma representação dcb/dcz. A hash incluída nos formatos liga o fluxo comprimido ao dicionário correto para decodificação. Ela não certifica que a resposta é atual, que corresponde a uma autorização, que foi compreendida ou que produziu efeito.

O cache preserva outro limite. Uma resposta comprimida com dicionário que possa ser armazenada deve variar por Accept-Encoding e Available-Dictionary. A regra impede que uma variante com o dicionário errado chegue a outro cliente. Não transforma a chave HTTP numa descrição completa de um estado comercial, de uma permissão, de um preço ou de uma configuração. Uma variante tecnicamente correta pode ser inadequada para uma decisão que depende de fatos fora desse cache.

O RFC também trata a segurança sem atalhos. O mecanismo é restrito a contextos seguros e ao mesmo origin. Falhas nas mitigacões exigidas levam o cliente a descartar a resposta. A compressão de dados públicos com dados privados pode vazar informação por tamanho ou tempo; hashes de dicionário recebem tratamento de estado rastreável, com partição e limpeza semelhantes às de cookies. Essas salvaguardas são necessárias, mas não concedem direito de ação.

O link compression-dictionary só sugere que um recurso relacionado talvez seja útil no futuro. O cliente decide se busca esse recurso; a resposta obtida ainda precisa de Use-As-Dictionary e metadados de cache. Sugerir uma busca não prova busca, uso ou resultado.

Para operar com rigor, mantenha uma cadeia: bytes e hash do dicionário, teste de origem e validade, destino, anúncio do cliente, codificação escolhida, variante, decodificação, semântica e a decisão posterior. RFC 9842 melhora a eficiência da entrega. A liderança não deve permitir que essa eficiência seja convertida em uma alegação de autoridade.

Fontes