Resumo

  • A RFC 9659 exige que decoders HTTP zstd suportem janelas de até 8 MB, inclusive, e proíbe encoders de emitir frames que exijam mais.
  • Um fallback bem-sucedido pode melhorar a experiência de um grupo sem provar que a variante zstd defeituosa foi separada, invalidada ou deixou de atingir outros clientes.
  • A evidência precisa unir frame, transformação, chave e geração de cache, limite efetivo do decoder, resultado do fallback e aceitação da aplicação.

O primeiro grupo de clientes falhou ao abrir uma resposta zstd; a mitigação retirou o coding para eles e serviu gzip. O indicador de erro caiu. Essa queda não demonstra que a causa foi removida. Se a chave de variante ou a invalidação estiver incompleta, um objeto antigo com janela excessiva pode continuar disponível para clientes que ainda anunciam zstd. O fallback funciona, mas a fronteira de responsabilidade fica invisível.

A RFC 9659 estabelece uma regra bilateral para o content coding HTTP zstd: o decoder DEVE aceitar Window_Size de até 8 MB, inclusive, e o encoder NÃO DEVE produzir frame que requeira janela maior. A regra protege o receptor contra uma exigência de memória arbitrária e dá ao produtor um alvo comum de interoperabilidade. Ela não afirma que toda variante armazenada obedece ao alvo.

A janela viaja dentro do frame

A RFC 8878 descreve o formato Zstandard. A janela limita a distância das referências a dados já decodificados e participa do estado que o decoder precisa manter. O formato admite desde 1 KB até cerca de 3,75 TB. Janelas maiores podem melhorar a compressão, mas transferem custo de memória ao destinatário.

Antes da RFC 9659, a RFC 8878 recomendava 8 MB para uso HTTP sem impor a linha. Um encoder podia usar mais em busca de eficiência, enquanto um navegador recusava o frame para proteger recursos. A nova RFC torna obrigatória a simetria. O texto canônico e a fonte XML preservam a formulação exata.

A página de informação do RFC Editor registra que a RFC 9659 é Informational e atualiza a RFC 8878. A consulta de errata e o histórico no Datatracker permitem versionar a política interna contra o estado público do documento.

Negociado não significa decodificado

A RFC 9110 define a semântica dos content codings. Accept-Encoding: zstd participa da seleção; Content-Encoding: zstd descreve a transformação da representação. Nenhum desses campos revela a janela do frame. Eles também não provam qual encoder foi usado, se um intermediário recomprimiu, se o processo tinha memória suficiente ou se a aplicação aceitou o conteúdo.

Por isso, uma métrica de “respostas zstd” pode ser correta e insuficiente. O servidor conta a decisão antes do decode. O edge registra HTTP 200 antes do cliente. Um canário pequeno não alcança a janela de um objeto grande. O mesmo agente pode rodar em dispositivos e limites diferentes. O token nomeia um contrato; não entrega o recibo do resultado.

A RFC 7694 mostra a mesma separação no sentido de request content: anunciar os codings que o servidor aceita não prova o processamento de um corpo específico. Oferta, escolha, bytes e resultado precisam permanecer separados nos dois sentidos.

Fallback sem identidade pode contaminar o cache

A RFC 9111 torna o cache parte do caminho semântico. Variantes escolhidas por Accept-Encoding precisam de chaves e validação coerentes. Se o fallback para gzip for armazenado de maneira ambígua, pode ser servido a quem esperava outra representação. Se a variante zstd incorreta não for invalidada em todas as gerações, ela continua circulando apesar da melhora agregada.

O recibo deve identificar objeto e variante: hash, chave, geração, idade, Vary relevante, invalidação, origem, transformação e frame. Deve também mostrar qual população recebeu o fallback e qual continuou recebendo zstd. Sem essa separação, a mitigação muda a amostra observada e pode produzir uma falsa sensação de correção.

O registro IANA de parâmetros HTTP agora descreve zstd como um stream Zstandard com Window_Size de no máximo 8 MB. O registro fixa o significado público. Não remove objetos antigos nem impede recompressão errada. A expectativa nasce no registro; a conformidade vive nos bytes.

Suporte do decoder e orçamento real não são sinônimos

Uma biblioteca pode suportar 8 MB e ainda ser chamada por um processo com limite menor. Pressão de memória, concorrência, configuração de container ou timeout podem interromper o decode. Depois dele, parsing e validação da aplicação também podem falhar. A frase “o cliente suporta zstd” precisa de versão, configuração, instante e resultado.

O lado receptor deve registrar agente ou biblioteca, limite efetivo, janela observada, resultado e erro classificado. Frame acima de 8 MB, truncamento, corrupção, coding desconhecido, falha de alocação, problema de dicionário e rejeição da aplicação não devem virar uma única contagem.

A RFC 9659 observa que decoders ainda podem receber frames sobredimensionados e não conformes, e falhar. O suporte obrigatório até 8 MB não exige memória infinita. Rejeitar corretamente uma entrada fora do contrato é diferente de falhar dentro do contrato.

dcz possui outra fronteira

A RFC 9842 define Compression Dictionary Transport e o coding dcz. Nesse contexto, a janela pode depender do tamanho do dicionário e chegar a 128 MB. É outro coding e outro acordo. A regra não autoriza zstd comum acima do limite de 8 MB da RFC 9659.

Uma biblioteca compartilhada pode expor um controle genérico de janela e esconder a diferença. A prova deve manter token, identidade do dicionário e contexto do frame. Reutilização de software não transforma contratos de protocolo distintos em um único contrato.

Da configuração ao resultado

No produtor, guardar versão do encoder, configuração efetiva, coding, hash do objeto e header do frame. Em cada intermediário, registrar passagem, decode, recompressão ou substituição. No cache, guardar chave, geração, frescor e invalidação. No receptor, guardar versão, orçamento, janela, resultado e erro. Na aplicação, registrar aceitação em vez de inferi-la do transporte.

Amostragem bem escolhida cobre objetos grandes, gerações antigas, edges regionais, clientes restritos, rollback, fallback e mudanças de chave. Alertas devem captar frame acima de 8 MB, diferença de hash sem transformação, objeto antigo após mudança do cap, mistura de variantes e divergência entre negociação e conclusão da aplicação.

A Minimum Initial Specification de Heng Lu oferece uma forma institucional: uma regra comum pequena — 8 MB e falha explícita — com liberdade local dentro dela. As Reality Layers impedem que o nome zstd receba a autoridade do decode. A Running-Code Primacy dá a última palavra ao frame servido e ao receptor executado.

A RFC 9659 torna o limite legível. O fallback só é uma solução quando também existe prova de que as variantes permaneceram separadas e o resultado chegou à aplicação.

Fontes